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Section  1 
INTRODUCTION 


1.1  ONBOARD  TEST  SYSTEM 

1.1.1  DEFINITION 

The  test  system  around  which  this  design  guide  is  structured  is  a  special 
form  of  Built-in-Test  (BIT)  and  conforms  most  closely  to  a  combination  of  the 
established  definitions  for  Built-in-Test  Equipment  (BITE)  and  Automatic  Test 
Equipment  (ATE)  as  listed  in  MIL-STD-1309  (Definitions  of  Terms  for  Test,  Meas¬ 
urement,  and  Diagnostic  Equipment).  In  the  absence  of  an  existing  singular 
definition  for  Onboard  Test  System,  the  following  definition  has  been  developed 
and  will  apply  throughout  this  document. 

Onboard  Test  System  -  Equipment  that  is  designed  to 
interface  with  or  is  part  of  an  on-line  system,  sub¬ 
system,  or  other  equipment  on  a  continuous  basis  for 
the  express  purpose  of  analyzing  functional  or  static 
parameters  to  evaluate  the  degree  of  performance  de¬ 
gradation  and  perform  fault  isolation  of  unit  mal¬ 
functions.  The  test,  logic,  and  control  functions 
are  essentially  automatic,  with  a  minimum  of  operator 
participation. 

1.1.2  PURPOSE 

The  purpose  of  an  onboard  test  system  is  to  test  and  verify  the  performance 
of  a  system,  subsystem,  or  other  equipment  in  an  operational  environment.  In 
addition,  the  onboard  test  system  provides  identification  of  a  malfunctioning 
Line  Replaceable  Unit  (LRU)  and  displays  the  test  and  fault  isolation  results. 
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1.1.3  BENEFITS 

The  prime  benefit  to  be  realized  from  the  use  of  an  onboard  test  system  is 
the  reduction  of  cost  of  maintenance.  This  reduction  is  brought  about  through 
several  cost-related  factors.  The  time  required  for  maintenance  can  be  short¬ 
ened  considerably  by  decreasing  the  time  necessary  to  detect  and  isolate  fail¬ 
ures;  the  time  lost  by  incorrect  detection/isolation  of  failures  can  be  reduced; 
the  skill  level  requirement  for  maintenance  technicians  can  be  lowered  without 
sacrificing  quality  or  speed  of  detection  and  isolation;  test  equipment  can  be 
reduced  in  quantity  and  complexity;  training  equipment  can  be  reduced  in  quantity 
ard  complexity;  maintenance  of  test  and  training  equipment  can  be  reduced;  and 
the  number  of  maintenance  and  training  personnel  can  be  reduced.  Attendant  to 
the  cost-reducing  benefits  will  be  an  increased  availability  of  the  system  under 
test,  increased  probability  of  mission  success,  and  increased  safety  of  operation. 

1.2  DESIGN  GUIDE 

1.2.1  PURPOSE 

If  the  purpose  of  the  onboard  test  system  is  to  be  fulfilled,  the  design 
of  the  test  system  must  satisfy  two  conditions.  The  first  condition,  of  course, 
is  that  the  performance  requirements  established  by  the  customer  are  met. 

Secondly,  the  cost  of  development  plus  on-going  costs  of  ownership  must  not 
outweigh  the  cost  advantages  realized  from  the  planned  application  of  the  test 
system. 

The  purpose  of  this  design  guide  is  to  provide  a  philosophy  and  approach 
to  the  overall  task  of  developing  an  onboard  test  system  which  will  allow  an 
optimized  design  from  the  standpoint  of  the  two  conditions  mentioned  above. 

1.2.2  CONTENT 

The  design  guide  includes  sections  on  the  background  and  history  of  on¬ 
board  testing,  the  analysis  of  test  requirements,  the  analysis  of  hardware 
requirements,  the  analysis  of  software  requirements,  signal  processing,  and 
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self-test.  The  various  sections  will  present  a  series  of  guidelines  for 
developing  a  test  system,  beginning  with  a  test  approach  and  proceeding  through 
a  logical  sequence  of  tasks  involving  selections  of  test  parameters,  test  sensors, 
interfacing  methods,  and  test  techniques  from  available  alternatives,  taking 
into  account  at  all  times  the  determining  factors  of  requirements  such  as  levels 
of  detection,  degree  of  isolation,  safety,  testability,  availability,  and  cost. 
Although  no  one  set  of  rules,  guidelines,  or  limitations  can  be  made  which  would 
apply  specifically  in  all  aspects  and  details  for  all  possible  combinations  of 
requirements  imposed  by  a  procurement  agency  or  customer,  the  contents  of  this 
design  guide  cover  those  areas  of  concern  which  are  of  prime  importance  and 
significance  in  a  disciplined,  phased  development  of  a  functionally  sound  and 
cost-effective  onboard  test  system. 

1.2.3  FORMAT 

The  sequence  of  presentation  of  the  material  in  this  document  is  such  that 
the  user  is  spared  the  need  for  interrupting  the  normal  flow  of  his  efforts  with 
topics  which  are  not  immediately  pertinent.  References  to  material  in  outside 
sources  or  in  other  sections  of  the  design  guide  are  kept  to  a  minimum  within 
procedural  text  and,  if  necessary,  material  will  be  repeated  from  one  section 
to  another  to  avoid  disrupting  an  orderly  approach  to  a  particular  task.  Within 
each  section  of  the  design  guide  subject  matter  is  arranged  according  to  pri¬ 
orities  of  importance  and  with  respect  to  the  interdependencies  of  the  steps 
or  phases  involved.  In  other  words,  first-things-first  and  nice-to-know  things 
last. 

It  is  realized  that  future  development  and  results  of  other  programs  will 
produce  information  which  will  prompt  additions,  deletions,  and  revisions  to 
this  design  guide.  These  changes  are  not  only  expected,  but  are  encouraged 
and  every  effort  has  been  made  to  format  this  document  to  accommodate  such 
changes  efficiently. 
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1.3  SUM4ARY 


This  design  guide  defines  and  describes  an  onboard  test  system  to  be 
designed  and  developed  as  a  future  system,  based  on  past  experiences  with 
BIT,  BITE,  ATE,  Central  Integrated  Test  System  (CITS),  and  other  test  systems. 
Guidelines  and  ground  rules  are  presented  for  the  development  of  such  an 
onboard  test  system  beginning  from  the  conceptual  stage  and  continuing  through 
to  delivery  and  acceptance  of  hardware  and  software. 


Section  2 

ONBOARD  TEST  PHILOSOPHY 

2.1  EVOLUTION  OF  ONBOARD  TESTING 

Since  the  advent  of  aircraft  electronic  systems,  the  complexity  of  those 
systems  has  gradually  but  steadily  become  more  complex.  As  a  direct  result, 
the  ratio  of  maintenance  manhours  to  flight  hours  has  increased,  higher  skill - 
level  maintenance  men  have  been  required,  and  aircraft  maintenance  times  have 
increased  to  a  point  where  the  repair  times  of  the  aircraft  were  seriously  im¬ 
pacting  aircraft  availability  requirements. 

Early  testing  of  aircraft  systems  was  relatively  simple  and  could  be  ac¬ 
complished  using  manual  procedures  utilizing  discrete  measurements  of  operational 
signals.  As  long  as  the  systems  were  of  low  complexity  the  main  problems  en¬ 
countered  were  personnel  safety,  LRU  access,  and  connector  damage  due  to  improper 
handling.  The  quality  of  maintenance  was  directly  dependent  on  the  knowledge 
and  skills  of  the  technicians  and,  therefore,  varied  greatly  from  unit  to  unit 
as  individuals  developed  their  own  troubleshooting  techniques.  There  was  no 
general  agreement  on  test  approach  or  methods  and  no  special  attempts  were  made 
to  standardize  them.  As  each  new  generation  of  aircraft  developed,  maintenance 
requirements  and  procedures  were  increased  to  a  point  that  later  generation  air¬ 
craft  were  surrounded  by  support  equipment  and  maintenance  personnel  in  order  to 
perform  system  fault  detection,  isolation,  repair,  and  system  reverification. 

As  maintenance  demands  upon  the  maintenance  personnel  increased,  shortcut  methods 
were  often  substituted  for  approved  maintenance  procedures.  The  most  comnon  and 
most  costly  shortcut  method  employed  was  that  of  LRU  failure  isolation  by  LRU 
substitution.  LRU  substitution  was  based  upon  the  maintenance  man's  prior  ex¬ 
perience  where  a  similar  failure  was  rectified  by  replacing  a  particular  LRU, 
or  because  the  LRU  was  accessible  and  easily  replaced,  or  because  it  was  assumed 
that  through  the  process  of  elimination  the  failure  would  be  found.  This  method 
of  fault  isolation  created  sparing  problems,  induced  failures,  and  also  increased 
the  cost  of  maintenance  due  to  the  replacement  of  units  that  had  not  failed  and 
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the  unnecessary  cycling  of  these  units  through  the  Intermediate  and/or  Depot 
maintenance  facilities  for  reverification. 

Over  the  years,  several  significant  attempts  to  improve  the  maintenance 
situation  have  occurred.  Each  attempt  resulted  in  some  progress,  but  has  never 
completely  eliminated  all  the  problems.  These  events,  leading  up  to  the  present 
time,  are  discussed  below. 

2.1.1  TEST  POINTS 

In  an  effort  to  alleviate  the  problems  associated  with  operational  con¬ 
nectors  and  LRU  substitution,  special  requirements  were  imposed  on  equipment 
manufacturers  for  the  inclusion  of  test  points,  preselected  for  maximum  appli¬ 
cability  to  manual  troubleshooting  procedures  and  measurements,  in  the  design 
of  their  equipments.  These  test  points  were  provided  in  two  different  ways. 

2. 1.1.1  Probe  Access 

Manual  probing  of  voltages  at  points  within  equipment  with  limited  or 
obstructed  access  has  always  presented  the  possibility  of  damage  to  equipment 
or  harm  to  personnel.  An  attempt  to  reduce  these  possibilities  and  add  to  the 
ease  of  maintenance  was  made  by  providing  electrical  access  to  pertinent  points 
within  equipment  circuitry  at  terminal  posts  or  terminal  boards  which  were 
physically  arranged,  located,  and  identified  to  facilitate  testing  and  trouble¬ 
shooting  through  manual  probing.  This  feature  also  reduced  the  practice  of 
probing  at  operational  electrical  connectors. 

2. 1.1. 2  Connectors  for  External  Test  Equipment 

In  a  further  effort  to  provide  test  point  accessibility  without  the  removal 
of  LRU  covers  or  cases,  manufacturers  were  required  to  route  test  points  to 
special  test  connectors  on  the  face  of  the  LRU.  These  special  connectors  pro¬ 
vided  a  more  efficient  means  of  interfacing  LRU  test  points  with  test,  measurement, 
and  diagnostic  equipment  (TMDE) ,  which  included  special  test  harnesses  or  cables 
to  provide  proper  interface  connections. 
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2.1.2  BUILT- IN-TEST  (BIT) 

Although  test  points  and  test  connectors  were  useful  for  aircraft  checkout, 
the  time  required  to  open  equipment  bays,  connect  test  equipment,  and  perform 
manual  checkout  again  compromised  aircraft  availability  requirements  as  the  air¬ 
craft  systems  grew  in  complexity. 

It  was  at  this  time  that  additional  requirements  were  developed  for  cir¬ 
cuitry,  components,  and  devices  to  be  included  in  operational  equipment  for  the 
sole  purpose  of  providing  aids  to  testing.  These  aids  included  means  for  exer¬ 
cising  or  stimulating  equipment  or  portions  of  equipment  (self-test) ,  means  for 
visually  observing  self-test  results  (GO/NO-GO) ,  or  means  for  visually  observing 
the  value  of  key  voltages  or  other  measurable  parameters.  These  provisions  ranged 
from  simple  indicator  lamps  or  meter  displays  to  manual  initiation  of  test  se¬ 
quences  which  stimulate  subsystem  equipment  and  verify  proper  response  charac¬ 
teristics.  It  was  only  natural  that  these  provisions  were  referred  to  as  "built - 
in-test,"  and  the  components  or  devices  were  known  as  "built-in-test  equipment." 

2.1.3  ONBOARD  TEST  SYSTEM 

In  the  interest  of  meeting  higher  system  availability  requirements  and 
still  lowering  life  cycle  costs  associated  with  maintenance  manhours,  skill- 
levels,  support  equipment  costs,  and  spares  cost,  it  became  apparent  that  the 
testing  of  systems  should  be  accomplished  during  normal  system  operating  times 
and  that  sufficient  maintenance  data  be  provided  to  the  ground  crew  to  allow 
the  maintenance  to  be  performed  without  the  need  for  running  ground  tests  to 
detect  and  isolate  the  system  failures.  This  could  only  be  done  by  performing 
the  fault  detection  and  fault  isolation  testing  using  on-aircraft  test  equip¬ 
ment.  It  was  also  apparent  that  to  physically  transfer  operational  support 
equipment  test  concepts  onto  the  aircraft  would  require  a  great  deal  of  equip¬ 
ment  and  would  add  significant  weight  to  the  aircraft.  Obviously,  the  tradi¬ 
tional  methods  of  fault  detection  and  fault  isolation  testing  would  have  to  be 
changed  if  cost  effective  on-aircraft  testing  was  going  to  become  a  reality. 

About  the  same  time,  system  designers  recognized  that  the  maintenance  of  systems 
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was  less  costly  and  easier  if  operational  functions  were  designed  into  func¬ 
tionally  replaceable  units,  i.e.,  single  boxes,  cards,  or  modules.  The  results 
of  this  functional  packaging  development  permitted  end-to-end  functional  testing 
which  eliminated  the  need  for  discrete  component  measurements  to  perform  fault 
isolation  to  a  replaceable  unit.  Also,  onboard  test  designers  recognized  that 
computer  techniques  could  be  used  to  identify  and  perform  logical  patterns  of 
functional  parameters  to  identify  faults  and  isolate  the  fault  to  the  defective 
LRU.  The  breakthrough  of  on-aircraft  test  technology  was  then  provided  by  the 
development  of  digital  airborne  technology.  This  allowed  the  testing  of  air¬ 
craft  systems  to  be  performed  by  using  end-to-end  functional  testing  instead 
of  by  discrete  measurements.  Systems  engineering  analysis  of  onboard  test 
operations  identified  three  primary  functions  required  for  performing  onboard 
testing.  These  functions  are  data  acquisition,  data  processing,  and  data  dis¬ 
semination.  Further  analysis  of  available  building  block  technology  and  cost 
trade-offs  revealed  that  the  lower  cost  candidate  was  districted  da*  .  acqui¬ 
sition  and  centralized  data  processing  and  data  di s seminar ion.  In  addition, 
by  centralizing  the  onboard  test  system  controls  and  displays,  a  secondary 
cost  reduction  could  be  achieved  by  making  the  test  system  control  and  display 
comnon  for  both  flight  and  ground  personnel.  Subsequent  experience  has  further 
revealed  that  the  on-aircraft  availability  of  aircraft  systems  functional 
parameters  is  a  valuable  asset  to  the  flight  operations  of  the  aircraft. 

Operational  and  support  analysis  indicated  the  need  for  providing  a  per¬ 
manent  record  of  all  detected  failures  and  isolated  units  to  the  ground  main¬ 
tenance  crew  and  logistics  support  functions.  The  requirement  for  a  permanent 
record  is  best  satisfied  by  high  density  digital  magnetic  recording  techniques 
in  that  the  stored  fault  detection/isolation  data  is  easily  transferred  to 
ground  processing  centers.  However,  significant  delays  can  be  encountered  in 
processing  the  records  and  providing  the  in-flight  test  data  and  isolation 
results  that  permits  ground  personnel  to  start  repair  actions  on  the  aircraft. 

A  second  problem  of  providing  maintenance  data  existed  concerning  aircraft 
operations  at  austere  bases  where  ground  processing  equipment  was  not  available. 


Therefore,  a  means  was  sought  to  provide  the  ground  crew  with  fault  isolation 
and  fault  isolation  data  iumediately  after  aircraft  shutdown.  Trade  studies 
of  available  technology  indicated  that  a  hard  copy  printer  could  satisfy  this 
requirement.  Although  all  test  systems  require  some  degree  of  operator  actions, 
some  test  system  concepts  require  considerably  more  operator  involvement  than 
others.  This  degree  of  operator  involvement  is  the  key  factor  in  comparing  two 
basic  categories  of  onboard  test  systems  below. 

2.1. 3.1  Semi-Automatic  Control 

The  first  category  of  onboard  test  system  utilizes  semi-automatic  operator 
involvement.  In  this  test  system,  signals  may  be  accessed  and  processed  auto¬ 
matically,  and  the  failure  display  may  indicate  which  subsystem  failed,  or  the 
subsystem  operational  mode  that  has  been  lost,  or  a  signal  that  was  found  to  be 
out  of  tolerance.  The  operator  must  then  consult  a  troubleshooting  procedure 
or  depend  on  his  own  ingenuity  to  troubleshoot  a  subsystem  malfunction  and 
isolate  the  failure  to  an  LRU.  Should  a  troublehsooting  procedure  be  required, 
much  time  would  be  consumed  in  the  manual  interrogation  of  test  signals  or  the 
necessity  to  connect  and  utilize  TMDE.  In  the  event  that  no  troubleshooting 
procedure  exists,  the  operator  must  be  of  sufficient  skill  level  and  possess 
sufficient  subsystem  knowledge  to  effectively  isolate  subsystem  faults.  This 
additional  skill  level  and  knowledge  would,  of  course,  result  in  higher  main¬ 
tenance  cost.  During  the  development  phase  of  the  B-l  aircraft,  a  study  was 
made  which  concluded  that  a  technician  skill  level  3  would  be  required  to  main¬ 
tain  the  aircraft  equipped  with  CITS,  whereas  the  same  aircraft  without  the 
CITS  would  have  required  a  skill  level  of  5.  Taking  into  account  the  estimated 
reduction  of  the  number  of  maintenance  men  required,  the  dollar  savings  (cor¬ 
rected  to  1979  dollars)  was  calculated  to  be  $12,667  per  year  per  aircraft. 


2. 1.3. 2  Automatic  Control 


The  automatic  control  test  system  requires  considerably  less  operator 
involvement  than  the  semi-automatic  system.  Like  the  semi-automatic  system, 
the  test  signals  are  accessed  and  processed  automatically. 

The  major  difference  between  the  automatic  system  and  the  semi-automatic 
system  is  that  the  contents  of  the  semi-automatic  troubleshooting  procedures 
and  the  operator's  ingenuity  have  been  incorporated  into  the  automatic  sys¬ 
tems's  computer  software. 

With  the  automatic  system,  the  maximum  skill  level  required  for  main¬ 
tenance  personnel  is  considerably  lower  and  maintenance  times  are  reduced  to 
include  only  remove,  replace,  and  retest  times.  The  additional  cost  of  the 
automatic  test  system  equipment,  software,  and  development  is  more  than  off¬ 
set  by  lower  maintenance  costs  and  increased  aircraft  availability,  assuming, 
of  course,  that  the  test  system  design  is  based  on  a  judicious  selection  of 
*ests  and  test  hardware  which  involves  consideration  of  failure  rates,  cost, 
and  ease  of  implementation.  These  and  other  factors  are  discussed  in  greater 
detail  in  Section  3  and  4. 

2.2  BASIC  ASSUMPTIONS  AND  DEFINITIONS 

2.2.1  ASSUMPTIONS 

In  order  to  arrive  at  a  definite  starting  point  in  the  procedure  of  estab¬ 
lishing  guidelines  and  instructions  for  designers,  it  was  nessary  to  make 
certain  assumptions  which,  if  not  stated  would  allow  a  great  deal  of  the  ensu¬ 
ing  material  to  be  misconstrued,  perhaps  to  the  extent  of  delaying  the  eventual 
optimization  of  the  onboard  test  system  design.  These  assumptions  are  given 
in  the  following  paragraphs. 

2. 2. 1.1  Acquisition  Decisions 

The  decision  to  incorporate  an  onboard  test  system  has  been  made  by  the 
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customer  and  requirements  governing  application  and  performance  have  been 
established  and  delineated  based  on  the  results  of  studies  made  starting  with 
the  conceptual  phase  in  accordance  with  the  guidelines  set  forth  in  this  doc¬ 
ument. 

2. 2. 1.2  User  Level 

The  top  level  user  in  this  design  guide  will  be  the  Air  Force  Program 
Office  (PO)  and/or  a  weapons  systems  prime  contractor. 

Although  this  design  guide  is  prepared  for  universal  application,  where¬ 
by  designers  at  all  levels  of  effort  may  be  involved,  it  was  decided  to  pre¬ 
sent  the  material  as  though  the  development  of  the  onboard  test  system  is  to 
be  the  responsibility  of  the  Air  Force  PO  and/or  a  single  prime  contractor  of 
a  complete  weapon  system.  The  prime  contractor  is  assumed  to  take  on  the  role 
of  an  integrator,  whereby  systems,  subsystems,  and  equipment  are  procured  from 
subcontractors,  or  suppliers  either  totally  or  in  part,  with  the  design  require¬ 
ments  delineated  and  imposed  b;  the  prime  contractor.  The  total  integration 
of  each  system  or  subsystem,  including  the  onboard  test  system,  with  each  other 
into  a  weapons  system  as  the  function  of  the  prime  contractor  does  not,  however, 
preclude  the  use  of  the  design  guide  by  designers  working  under  different,  less 
extensive  contract  arrangements. 

2. 2. 1.3  Test  System  Usage 

The  onboard  test  system  is  for  the  sole  purpose  of  testing.  No  portion  of 
the  test  system  will  be  involved  in  the  normal  operation  of  any  of  the  systems 
under  test. 

Provisions  for  "fail  safe"  operation  incorporated  in  aircraft  systems  be¬ 
cause  of  safety  or  mission  success  requirements,  whereby  a  failure  of  the  system 
initiates  an  action  which  switches  faulty  parts  or  circuitry  out  and  automatically 
inserts  backup  redundant  parts  or  circuitry  to  prevent  the  loss  of  unacceptable 
degradation  of  the  system  function,  are  not  considered  to  be  a  portion  of  the 
onboard  test  system.  The  distinction  is  made  in  accordance  with  the  requirement 
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that  the  onboard  test  system  is  prohibited  from  the  automatic  initiation  or 
control  of  switching  of  subsystems,  functions,  or  modes  (see  paragraph 
3. 1.1. 6. 2). 

2. 2. 1.4  Design  Timing 

Design  of  the  test  system  will  be  concurrent  with  the  design/selection 
of  the  systems  conprising  the  weapons  system. 

The  basic  content  of  the  design  guide  is  based  on  the  development  and 
design  of  totally  new  systems  and  subsystems  to  be  tested  by  an  onboard  test 
system  which  is  also  to  be  developed  and  designed  as  a  new  system.  However, 
the  adaptation  of  an  existing  system,  subsystem,  or  equipment  design  to  a 
new  onboard  test  system  design  (or  vice  versa)  can  be  directly  addressed,  by 
following  the  same  guidelines,  with  certain  ramifications  to  be  identified 
in  those  instances  where  they  apply. 

2.2.2  DEFINITIONS 

MIL-STD-1309  is  used  as  the  reference  for  definitions  of  terms  used  in 
the  design  guide,  with  certain  exceptions. 

2. 2. 2.1  Standard  Definitions 

The  following  definitions  are  provided  for  convenience  in  using  the  design 
guide  and  are  listed  verbatim  from  MIL-STD-1309. 

2. 2. 2. 1.1  Built-In-Test  Equipment  (BITE) 

Any  device  which  is  part  of  an  equipment  or  system  and  is  used  for  the 
express  purpose  of  testing  the  equipment  or  system.  BITE  is  an  identifiable 
unit  of  the  equipment  or  system  (see  self-test). 

2. 2. 2. 1.2  Built-In-Test  (BIT) 

A  test  approach  using  BITE  or  self-test  hardware  or  software  to  test  all 
or  part  of  the  unit  under  test. 
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2. 2. 2. 1.3  Corrective  Maintenance 

Actions  performed  to  restore  a  failed  or  degraded  equipment.  It  includes 
fault  isolation,  repair  or  replacement  of  defective  units,  alignment,  and 
checkout. 

2. 2. 2. 1.4  Self-Test 

A  test  or  series  of  tests,  performed  by  a  device  upon  itself,  which  shows 
whether  or  not  it  is  operating  within  designed  limits.  This  includes  test 
programs  on  computers  and  automatic  test  equipment  which  check  out  their  per¬ 
formance  status  and  readiness. 

2. 2. 2. 1.5  Line  Replaceable  Unit  (LRU) 

A  unit  which  is  designated  by  the  plan  for  maintenance  to  be  removed 
upon  failure  from  a  larger  entity  (equipment,  system)  in  the  latter's  oper¬ 
ational  environment. 

2 . 2 . 2 . 1 . 6  Logic  Diagram 

A  graphic  representation  of  steps  and  branches  used  in  the  development 
of  test  sequences  and  procedures. 

2. 2. 2. 2  Exceptions 

The  following  definitions  are  exceptions  to  MIL-STD-1309.  These  except¬ 
ions  arise  due  to:  1)  Absence  of  definition,  2)  Incomplete  definition,  or 
3)  Inaccurate  definition.  Definitions  in  these  categories  are  given  below. 

2. 2. 2. 2.1  Availability 

The  probability,  expressed  as  a  percentage,  that  a  system,  subsystem,  or 
equipment  will  be  available  in  an  operationally  acceptable  condition  at  any 
time. 
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2 . 2 . 2 . 2 . 2  Degraded  Performance 

That  condition  of  a  system,  subsystem,  or  equipment  whereby  certain  crit¬ 
ical  parameters  have  deteriorated  to  values  below  expected  operating  levels 
but  above  failure  limits,  while  retaining  the  intended  function. 

2. 2. 2. 2. 3  Detection  Assurance 

The  probability,  expressed  as  a  percentage,  that  a  failure  of  a  system, 
subsystem,  or  equipment  under  test  will  be  detected  and  displayed  by  the  test 
system. 

2. 2. 2. 2. 4  Failure 

The  inability  of  a  system,  subsystem,  or  equipment  to  perform  its  intended 
function  in  accordance  with  the  performance  requirements  described  in  the 
appropriate  detail  performance  specification. 

2. 2. 2. 2.5  Failure  Mode 

That  system,  subsystem,  or  equipment  operational  function  lost  or  de¬ 
graded  as  the  result  of  a  particular  single  failure. 

2. 2. 2. 2.6  Failure  Mode  Rate 

That  figure  assigned  to  a  failure  mode  in  terms  of  occurrences  per  million 
hours  of  operation. 

2. 2. 2. 2. 7  Fault  Isolation 

The  determination  that  a  detected  failure  is  located  in  a  single  identi¬ 
fiable  LRU. 
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2. 2. 2. 2. 8  False  Indication 

An  indication  by  the  test  system  of  a  failure  of  a  system,  subsystem,  or 
equipment  when,  in  fact,  no  failure  exists;  or  the  absence  of  an  indication  by 
the  test  system  of  a  detectable  failure  of  a  system,  subsystem,  or  equipment 
when  the  failure  exists. 

2. 2. 2. 2. 9  Isolation  Certainty 

The  probability,  expressed  as  a  percentage,  that  the  test  system  can 
correctly  ascertain  and  indicate  which  LRU  must  be  removed  and  replaced  to 
correct  a  particular  detected  failure. 

2.2.2.2.10  Maintainabilty 

The  probability,  expressed  as  a  percentage,  that  a  system,  subsystem,  or 
equipment  can  be  maintained  in  an  operationally  acceptable  condition  through 
maintenance  procedures  which  do  not  exceed  a  given  time  period. 

2.2.2.2.11  Onboard  Test  System 

Equipment  that  is  designed  to  interface  with  or  is  part  of  an  on-line 
system,  subsystem,  or  equipment  on  a  continuous  basis  for  the  express  purpose 
of  analyzing  functional  or  static  parameters  to  evaluate  the  degree  of  per¬ 
formance  degradation  and  perform  fault  isolation  of  unit  malfunction.  The 
test,  logic,  and  control  functions  are  essentially  automatic,  with  a  minimum 
of  operator  participation. 

2.3  TEST  APPROACH  FACTORS 

To  obtain  an  optimum  test  system,  a  total  systems  engineering  approach 
of  integrating  the  functional  system  design,  test  system  design,  test  analysis, 
reliability  analysis,  and  maintainability  analysis  must  be  accomplished  con¬ 
currently. 
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Many  questions  concerning  test  approach  must  be  answered  and  the  appli¬ 
cable  requirements  established  to  arrive  at  an  effective  onboard  test  system. 

Some  of  the  more  important  items  that  must  be  considered  in  developing 
the  proper  test  approach  for  the  test  system  are  given  in  the  following  para¬ 
graphs. 


2.3.1  TEST  SYSTEM  PERFORMANCE  REQUIREMENTS 

Failure  detect ion/ fault  isolation  (FD/FI)  performance  requirements  for 
the  test  system  are  usually  expressed  as  an  assurance  level  (0  to  100  percent) 
that  a  fault  ’within  a  subsystem  will  be  detected  and  that  the  faulty  equipment 
will  be  isolated  to  a  single  LRU.  Since  each  functional  system/LRU  under  test 
has  a  level  that  can  be  practically  achieved,  it  becomes  necessary  that  the 
aggregate  FD/FI  capability  of  all  of  the  functional  systems/LRU's  being  tested 
equal  the  overall  test  system  FD/FI  performance. 

The  proper  establishment  and  allocation  of  the  test  performance  require¬ 
ments  for  the  individual  functional  systems  being  tested  provides  the  basis  for 
a  successful  cost  effective  test  system  implementation.  It  is,  therefore, 
imperative  that  good  engineering  judgement  and  proven  methods  be  utilized  in 
determining  the  extent  that  the  test  system  FD/FI  requirements  are  to  be  applied 
to  each  of  the  systems  under  test. 

2. 3. 1.1  Failure  Detection 

Failure  detection  is  the  means  of  monitoring  the  general  "well-being"  of 
the  functional  system  and  is  the  starting  point  in  the  isolation  of  the  failed 
equipment.  This  detection  testing  is  best  accomplished  by  utilizing  an  end- 
to-end  type  of  testing  for  the  functional  system.  This  end-to-end  testing 
monitors  the  input  data  to  the  operational  system  and  then  compares  it  with 
expected  output  data  to  determine  overall  system  performance. 
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2. 3. 1.1.1  Maintenance  Level 

Prime  consideration  must  be  given  to  the  maintenance  concept  under  which 
the  onboard  test  system  is  to  be  operated.  The  maintenance  level  at  which  the 
test  system  must  detect  and  isolate  failures  in  order  to  satisfy  maintenance 
requirements,  such  as  availability  and  maintainability,  influences  the  test 
approach  elements  of  test  selection,  parameter  selection,  and  test  logic. 

Maintenance  levels  are  typically  categorized  in  the  order  of  increasing 
maintenance  capability  as  organizational,  intermediate,  and  depot.  Organiza¬ 
tional  maintenance  is  performed  at  the  flight  line  by  the  operating  unit,  and 
consists  of  the  necessary  postflight  testing  to  isolate  failed  equipment, 
replacement  of  failed  LRU's,  system  reverification  after  maintenance  action, 
physical  inspections,  servicing  of  consumables,  handling,  and  preflight  read¬ 
iness  testing.  At  the  organizational  level,  the  onboard  test  system  provides 
system  failure  data  and  failure  isolation  to  the  LRU  level  which  enables  main¬ 
tenance  actions  to  begin  without  the  need  of  hooking  up  support  equipment, 
provides  reverifications  of  systems  after  maintenance  actions,  provides  pre¬ 
flight  checkout  of  the  aircraft,  and  provides  manual  troubleshooting  capability 
for  manual  fault  isolation. 

In  those  cases  where  isolation  ambiguity  exists,  or  where  isolation  is 
not  provided  automatically  by  the  test  system,  some  manual  troubleshooting 
procedure  must  be  employed  in  order  to  complete  the  maintenance  action.  The 
onboard  test  system  can  provide  special  features  which  allow  the  monitoring 
and  display  of  selected  aircraft  subsystem  parameters  on  an  individual  basis. 
This  feature  would  preclude  the  necessity  for  disconnecting  equipment,  removing 
equipment,  gaining  physical  access,  or  using  special  test  equipment  in  many 
cases  when  troubleshooting  at  the  organizational  level.  Intermediate  main¬ 
tenance  is  performed  at  centrally  located  facilities  in  support  of  the  oper¬ 
ating  units  and  consists  of  repair,  modifications,  and  test  of  components  re- 
quring  shop  facilities  not  available  at  the  organizational  level.  An  onboard 
test  system  can  contribute  to  this  type  of  maintenance  by  providing  data 
obtained  during  testing  at  the  organizational  level  if  the  test  system  is 
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designed  to  provide  isolation  to  the  failure  mode  as  well  as  identification 
of  the  failed  LRU  level.  Depot  maintenance  is  performed  in  industrial -type 
facilities,  including  contractor  plants,  and  consists  of  overhaul  and  repair 
of  components  beyond  the  capability  of  the  intermediate  or  organizational  work 
level.  Again,  an  onboard  test  system  can  enhance  maintenance  by  providing 
failure  mode  data  and  parameters  which  would  reduce  the  additional  requirements 
necessary  to  provide  failure  isolation. 

2. 3. 1.1. 2  Detection  Assurance 

No  practical  test  system  impl mentation  will  be  able  to  detect  100  percent 
of  all  possible  system  faults.  This  is  not  unexpected  since  virtually  all 
testing  approaches  use  probabilistic  and  statistical  data  with  supporting 
rationale  to  prove  that  maximum  detection  is  being  accomplished  within  rea¬ 
sonable  restraints.  However,  the  detection  assurance  requirements  will  normally 
be  expressed  as  a  high  percentage  of  the  total  system  failure  rate  based  on  the 
data  contained  in  the  Failure  Modes  and  Effects  Analysis  (FMEA) .  In  addition, 
the  detection  requirement  may  specify  detection  of  all  failures  classified  as 
impacting  safety-of-flight  and  mission  success.  Consequently,  it  is  essential 
that  an  accurate  FMEA  be  provided  since  this  is  the  prime  document  utilized 
during  design  and  developed  in  the  verification  of  the  attainment  of  the 
detection  assurance  requirement. 

2.3.1. 2  Fault  Isolation 

Accurate  fault  isolation  to  the  failed  LRU  is  the  key  to  an  effective 
test  system  and  fulfillment  of  the  organizational  level  maintenance  testing 
requirement.  This  fault  isolation  requirement  can  only  be  achieved  through 
system  failure  analysis,  development  of  optimum  system  tests,  and  proper 
parameter  selection. 


2. 3. 1.2.1  Isolation  Certainty 

The  percentage  of  isolation  certainty  is  defined  as  a  result  of  studies 
performed  in  the  conceptual  phase  and  is  formulated  based  on  the  total  main¬ 
tenance  requirements.  Fulfillment  of  the  requirement  is  the  key  to  a  successful 
test  system,  since  isolation  to  a  failed,  defective,  or  malfunctioning  unit  with 
a  high  degree  of  confidence  is  the  ultimate  function  of  an  onboard  test  system. 

Accomplishment  of  this  isolation  provides  maintenance  personnel  with  that 
information  necessary  to  perform  corrective  actions  within  the  boundaries  of 
time  imposed  by  maintainability  requirements.  Obviously,  if  the  isolation  in¬ 
formation  provided  is  ambiguous  or  incorrect,  additional  troubleshooting  must 
be  performed,  at  the  expense  of  time  allowed  for  maintenance. 

2. 3. 1.3  False  Indications 

False  indications  are  one  of  the  most  serious  problems  that  undermine  the 
effectiveness  of  a  test  system.  These  false  indications  occur  for  several 
reasons:  (a)  the  system  under  test  does  not  operate  as  expected;  (b)  the  test 
mechanization  is  incorrect;  (c)  the  software  is  programmed  incorrectly;  (d) 
failure  limits  have  been  set  too  tight  for  dynamic  conditions;  (e)  failure  of 
test  system  logic  circuitry;  or  (f)  test  parameters  affected  by  noise.  Resol¬ 
ution  of  these  false  indications  is  very  difficult  and  time  consuming  since 
adequate  test  data  must  be  recorded  and  analyzed  to  confirm  the  cause.  Each 
of  these  problems  requires  detailed  investigation  of  the  system  performance 
and  coordination  with  the  design  personnel,  system  supplier,  and  flight  test 
personnel  to  effect  an  optimum  resolution. 

During  the  flight  test  period  of  four  B-l  aircraft,  1,704  unique  failures 
were  annunciated  by  CITS,  and  of  these,  919  were,  classified  as  false  indications. 
The  causes  of  the  false  indications  experienced  were  studied  and  were  identified 
according  to  the  categories  listed  above.  Of  all  the  false  indications  studied, 
47  percent  were  of  category  (c) ,  27  percent  were  category  (b) ,  15  percent  were 
category  (a) ,  10  percent  were  category  (d) ,  with  the  remaining  1  percent  divided 
between  categories  (e)  and  (f) . 
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2.3.2  LIMITATICNS/RESTRICTIONS 

The  effectivness  of  the  test  system  can  be  severely  limited  when  the 
decision  to  include  test  system  requirements  are  implemented  late  (after  pre¬ 
liminary  design  review)  in  the  system  design  phase.  In  addition,  this  type 
of  implementation  usually  results  in  a  higher  cost  and  often  provides  an  over¬ 
all  design  which  is  far  from  satisfactory.  Even  when  the  test  system  design 
is  implemented  at  initial  design,  certain  limitations/restrictions  must  be 
considered  as  follows: 

2. 3. 2.1  Funct ional 

The  choices  of  tests  may  be  limited  by  functional  restrictions  such  as 
the  stipulation  that  only  noninterference  testing  may  be  used  in-flight,  where¬ 
by  the  use  of  stimuli  to  initiate  a  test  or  to  switch  operational  circuitry  is 
prohibited.  Although  not  usually  specifically  imposed  as  restrictions  in  the 
requirements,  dynamic  parameter  characteristics  such  as  rate  of  change,  fre¬ 
quency,  magnitude,  or  power  may  limit  the  selection  of  tests  and  thus  impact 
test  approach. 

2. 3. 2. 2  Physical 

The  physical  aspects  of  the  test  system  may  require  special  consideration 
depending  upon  the  system  being  tested.  The  special  considerations  may  include 
weight  allocations,  volume  limitations,  cooling  requirements,  and  accessibility. 

2. 3. 2. 3  Cost 

Since  the  test  system  must  be  designed  to  minimize  weapon  system  acqui¬ 
sition  costs  and  overall  life  cycle  costs,  it  is  essential  that  the  test  ap¬ 
proach  be  well  established  and  the  level  of  testing  be  clearly  defined  in 
order  to  meet  these  cost  objectives.  Consequently,  it  is  imperative  that  trade¬ 
off  studies  be  conducted  and  alternate  concepts,  methods,  and  techniques  be 
evaluated  in  the  process  of  arriving  at  an  optimum  cost  effective  test  system 
design. 
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Also,  since  the  recurring  cost  of  the  onboard  test  system  is  part  of  the 
flyaway  cost  of  the  aircraft,  onboard  test  system  benefits  to  total  weapon 
system  life  cycle  cost  must  be  clearly  understood  by  the  contractor  in  order 
that  effectiveness  of  the  test  system  is  not  compromised  at  the  expense  of 
increased  life  cycle  costs.  Life  cycle  cost  studies  of  the  total  weapon 
system  must  be  made  which  include  cost  factors  associated  with  the  reduced 
spares,  reduced  maintenance  manhours  per  flight  hour  (NMIFH) ,  reduced  skills 
levels,  reduced  support  equipment,  increased  availability,  and  increased 
alert  rate  benefits  provided  by  effective  onboard  testing.  A  recent  study 
was  made  comparing  the  life  cycle  cost  of  a  proposed  off-aircraft  ground 
test  set  (GTS)  to  the  life  cycle  cost  of  CITS,  as  applied  to  the  B-l  aircraft. 
The  results  are  shown  in  Table  II -1. 


LIFE  CYCLE  COST  SAVINGS  WITH  CITS 
Table  II -1 


Quantity  of 

v  ^\Aircraft 

Years 

55 

111 

165 

330 

10 

97.24  M 

158.21  M 

223.46  M 

401.35  M 

LCC 

Savings 

With 

CITS 

1979 

Dollars 

20 

162.55  M 

293.12  M 

415.12  M 

749.60  M 

30 

236.85  M 

428.10  M 

607.77  M 

1097.87  M 

2.4  ORGANIZATION,  MANAGEMENT,  AND  CONTROL 

The  overall  success  of  any  onboard  test  system  design  program  is  heavily 
influenced  by  the  structuring  of  the  test  system  design  group  and  related  work¬ 
ing  groups,  and  the  policies  and  procedures  governing  their  efforts. 

Ineffective  procedures  and  lack  of  control  contribute  materially  to  lost 
time  and  the  acceptance  of  less  than  optimum  testing  by  the  onboard  test  system 
in  many  areas.  Cooperation  from  other  groups  must  be  assured  by  the  presence 
of  a  strong  central  authority  with  the  ability  to  make  decisions  and  issue  direc¬ 
tives  to  resolve  differences  of  opinion  quickly  and  definitely.  Of  special  im¬ 
portance  is  the  ability  to  deal  directly  with  subcontractors  and  suppliers,  with 
full  authority  to  accept  or  reject  data  or  equipment,  as  necessary,  without  fear 
of  being  overruled  by  a  higher  authority  outside  the  test  system  complex  without 
adequate  coordination  and  discussion. 

2.4.1  ORGANIZATION 

The  assignment  of  engineering,  technical,  and  support  personnel  must  be 
made  purposefully  to  insure  proper  coverage  of  the  many  aspects  of  the  overall 
design,  development,  and  checkout  of  an  onboard  test  system.  These  assignments 
can  be  more  easily  determined  by  identifying  functional  tasks  and  grouping  per¬ 
sonnel  accordingly.  The  prime  purpose  is  to  avoid  the  need  for  broad  qual¬ 
ifications  in  any  one  area  below  the  category  of  management,  even  though  the 
various  functional  areas  may  be  quite  diverse  from  one  to  another. 

2. 4. 1.1  Contractor 

It  is  recommended  that  the  organization  of  the  onboard  test  system  group 
be  made  up  of  the  functional  units  and  subgroups  and  structured  as  shown  in 
figure  2-1.  This  is  a  basic  arrangement  and  is,  of  course,  subject  to  some 
variations,  depending  on  the  size  and  complexity  of  the  onboard  test  system 
and  the  application. 

The  separation  of  the  overall  design  function  into  the  subgroups  of  hard¬ 
ware  design,  software  design,  test  requirements,  and  integration  provides  for 
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better  visibility  and  control  of  these  definitive  areas  of  effort.  Further 
subdivision  is  necessary  to  better  take  advantage  of  established  skills  and 
expertise  and  to  allow  concentration  within  special  disciplines  at  the  lower 
levels.  The  designers  and  analysts  are  all  relieved  of  a  great  majority  of 
the  necessary  and  important  duties  of  integration,  whereby  the  more  routine 
and  less  technical  aspects  of  record  keeping,  internal  scheduling,  and  tracking, 
documentation  preparation  and  control,  change  control  and  general  overseeing 
of  compliance  to  formats,  procedures,  and  agreements  is  accomplished  by  per¬ 
sonnel  who  devote  their  full  time  to  these  particular  tasks.  It  is  found  that 
the  efficiency  of  engineers  and  other  technical  personnel  increases  with  a 
decrease  in  the  percentage  of  nontechnical  tasks  included  in  their  overall 
assignments  while,  at  the  same  time,  such  tasks  can  be  performed  much  better 
by  specialized  personnel  experienced  or  trained  in  such  matters.  The  end  result 
is  a  better  product,  produced  within  optimum  time  and  cost  frameworks. 

2. 4. 1.2  Customer 

It  is  felt  that  the  customer  should  provide  counterparts  for  contractor 
personnel  in  the  areas  of  hardware  design,  test  requirements,  and  software 
design  in  order  to  best  follow  and  evaluate  the  progress  of  the  program.  There 
is  no  particular  need  for  the  customer  to  provide  for  personnel  devoted  spe¬ 
cifically  to  the  integration  function  since  the  success  of  this  function  will 
be  reflected  in  the  normal  evaluation  and  coordination  process.  As  in  the 
case  of  the  contractor,  personnel  should  be  assigned  on  a  full  time  basis, 
not  being  required  to  share  time  on  the  onboard  test  system  program  with  any 
other  program,  nor  should  an  individual  be  required  to  perform  duties  or  accept 
responsibilities  outside  of  his  regularly  assigned  functional  area  within  the 
onboard  test  system  group. 


2-20 


2.4.2  MANAGEMENT 

Management  of  an  organization  involves  the  direction  and  control  of  per¬ 
sonnel  in  their  assigned  tasks.  This  management  is  provided  by  personnel  spe¬ 
cifically  designated  as  supervisor,  manager,  director,  chief,  or  some  other 
title,  depending  on  the  level  at  which  the  management  function  occurs  and  the 
definition  of  the  title  or  position.  Management  personnel  are  not  normally 
directly  involved  in  the  detailed  tasks  of  their  subordinates  but  are  suffi¬ 
ciently  knowledgeable  to  evaluate  problems  and  proposed  solutions  and  make 
related  decisions,  within  the  limits  of  their  immediate  responsibilities. 

2.4. 2.1  Customer 

Past  experience  in  the  development  of  onboard  test  systems  has  shown  that 
differences  of  philosophy  exist  within  the  customer's  organization  regarding 
the  requirements  for  and  the  implementation  of  an  onboard  test  system.  Even 
after  trade-off  and  life  cycle  cost  studies  were  completed  and  the  decision 
to  install  an  onboard  test  system  was  made,  conflicting  direction  from  the 
customer  was  received  by  the  contractor.  Some  elements  of  the  customer's 
organization  fully  supported  the  implementation  of  the  test  system  and  expressed 
their  support  and  direction  when  interfacing  with  their  contractor  counterparts. 
Other  elements  of  the  customer's  organization  did  not  fully  support  the  test 
contractor  counterparts.  These  differences  in  customer  direction  to  the  con¬ 
tractor's  various  design  groups  provided  confusion  and  difficulty  in  implementing 
the  test  system.  This  confusion  often  led  to  a  less  than  desirable  implementation 
of  the  test  system. 

It  is,  therefore,  obvious  that  a  single  management  point  of  interface  be 
established  by  the  customer  to  provide  direction  and  control  of  the  requirements 
for  the  test  system  development  and  implementation. 
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2 . 4 . 2 . 2  Contractor 


Similar  problems  occurred  in  the  customer's  organization  regarding  the 
degree  of  support  of  the  test  system  implementation  as  discussed  in  the  pre- 
ceeding  paragraph.  Because  of  this,  a  single  management  point  must  also  be 
established  by  the  contractor  to  provide  direction  and  control  of  the  test 
system  development  and  implementation  requirements  in  each  aircraft  system  to 
be  tested. 

2.4.3  CONTROL 

With  a  group  such  as  the  onboard  test  system  design  group  depicted  in 
figure  2-1,  control  can  be  established  and  maintained  because  the  lines  and 
levels  of  authority  are  clear  and  well  defined.  There  are  no  overlapping  or 
redundant  responsibilities  within  the  group  which  could  lead  to  conflicting 
directions  or  efforts.  However,  such  a  group  does  and  must  interface  with 
other  similar  groups,  both  within  the  same  basic  functional  management  struc¬ 
ture  and  with  other  groups  not  operating  under  the  same  discipline.  These 
disciplines  usually  include  engineering,  technical  operations,  logistics,  and 
finance,  each  with  their  own  groups  and  subgroups  working  on  a  particular  part 
of  the  overall  weapon  system.  The  degree  of  impact  one  has  on  another  varies, 
but  a  method  of  control  must  be  established  and  exercised  to  prevent  inpasses, 
not  only  between  contractor  elements  but  also  in  dealings  with  associate  con¬ 
tractors  and  subcontractors. 

2.4. 3.1  Aircraft  Systems  Design 

The  most  obvious  and  most  important  interface  of  the  rest  system  design 
group  is  that  with  the  group  or  groups  designing  the  various  aircraft  systems. 
Since  these  systems  are  to  be  tested  by  the  onboard-test  system,  it  is  only 
natural  that  their  design  affects  the  design  of  the  test  system.  These  design 
grotqps  may  be  within  the  prime  contractor's  organization,  may  be  an  associate 
contractor  group,  or  may  be  a  subcontractor  group. 
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2. 4. 3. 1.1  Contractor  In-House  Interfaces 

In  addition  to  the  internal  organization  of  the  onboard  test  system  design 
group  shown  in  figure  2-1,  it  is  also  necessary  to  establish  interfaces  and 
controls  outside  of  the  test  system  design  group.  There  are  seven  areas  that 
require  in-house  interface  and  control.  These  areas  are:  (1)  Aircraft  systems 
design;  (2)  Project  management;  (3)  Specifications;  (4)  Configuration  management 
and  change  administration;  (5)  Engineering  release  and  scheduling;  (6)  Contracts 
and  proposals;  and  (7)  Checkout  and  flight  test  operations.  These  interfaces 
are  shown  in  figure  2-2. 

When  implementing  an  onboard  test  system,  the  test  system  design  group  must 
interface  with  each  aircraft  subsystem  design  group  to  implement  the  test  re- 
requirements.  In-house  policies  and  procedures  must  be  set  up  to  control  this 
group -to -group  interface,  outlining  the  responsibilities  of  each  organization. 
These  procedures  must  provide  that  the  design  groups  have  joint  responsibilities 
of  implementing  the  test  requirements  into  each  aircraft  system  and  determining 
that  the  implementation  is  sufficient  to  meet  the  contractual  requirements  of 
the  test  system.  Any  deviations  from  the  stated  test  requirements  must  be 
approved  by  the  test  system  design  manager.  In  order  to  provide  a  uniform 
implementation  of  the  test  system  for  all  aircraft  systems,  an  onboard  test 
system  analyst  should  be  assigned  to  each  tested  aircraft  system.  It  would 
be  the  responsibility  of  these  analysts  to  interface  the  work  with  the  aircraft 
system  design  engineers  in  the  implementation  of  the  test  system  requirements. 

When  procurement  specifications  are  required  for  aircraft  systems  hard¬ 
ware,  these  specifications  must  include  an  onboard  test  requirements  section. 

A  test  verification  section  should  also  be  included  in  the  specification  which, 
as  a  minimum,  should  require  100  percent  onboard  test  interface  verification 
by  analysis  plus  a  percentage  of  verification  by  actual  hardware  tests.  This 
testing  should  be  conducted  using  fault  insertion  techniques  to  verify  predicted 
LRU  output  changes  associated  with  selected  failure  modes.  The  test  system 
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design  group  must  be  responsible  for  the  preparation  of  both  the  test  require¬ 
ments  and  verification  testing  sections  and  the  incorporation  of  the  sections 
into  the  procurement  specification  through  coordination  with  the  specifications 
group. 

Inner-group  control  of  design  changes  to  the  test  system,  whether  they  be 
to  hardware,  software,  or  test  requirements,  is  impacted  by  the  methods  and 
procedures  established  and  utilized  by  the  configuration  management  and  change 
administration  group.  Care  must  be  taken  to  conform  to  the  broader  control 
features  employed  on  the  weapon  system  program.  Similarily,  the  overall  weapon 
system  schedule  impacts  internal  controls  relating  to  test  system  design  sched¬ 
ules  and  milestones. 

2.4. 3. 1.2  Associate  Contractor  Interface 

An  associate  contractor  is  that  contractor  which  does  not  have  prime  re¬ 
sponsibility  for  an  overall  weapon  system,  but  is  under  contract  directly  with 
the  customer  for  a  particular  system,  subsystem,  or  other  portion  of  the  weapon 
system.  This  type  of  contractual  agreement  dictates  that  the  associate  con¬ 
tractor  is  accountable  directly  to  the  customer,  as  is  the  prime  contractor. 
Normally,  associate  contractors  are  responsible  for  the  design  and  integration 
of  major  subsystems  critical  to  the  overall  performance  of  the  total  system. 

In  this  capacity  they  have  an  obligation  to  be  involved  in  major  decisions  con¬ 
cerning  total  system  design.  To  perpetuate  controls  regarding  decisions, 
agreements,  and  technical  data  exchanges,  both  the  prime  and  associate  con¬ 
tractors  must  have  agreement  between  themselves  and  the  customer  prior  to 
design  implementation. 

When  interfacing  with  associate  contractors  there  are  several  tools  used 
to  retain  design  configuration  control:  (1)  Ch-site  technical  representative; 
(2)  Coordination  memorandums;  (3)  Memorandums  of  agreement;  and  (4)  Interface 
control  document.  Depending  on  complexity  of  system  design,  an  associate 
contractor's  technical  representative  should  be  on-site  at  the  prime  contractor’ 
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facility  on  a  continuing  basis.  In  this  way,  when  necessary,  face-to-face 
interface  between  the  two  contractors  can  be  accomplished.  Coordination  mem¬ 
orandums  are  used  when  official  (i.e.,  recorded  and  tracked)  correspondence 
is  desired.  By  utilizing  recorded  and  tracked  correspondence,  design  control 
can  be  obtained  because  all  of  the  pertinent  design  disciplines  would  review 
the  formal  paperwork  in  transit  to  or  from  the  contractor's  facility.  When 
critical  design  decisions  have  to  be  made  the  memorandum  of  agreement  documen¬ 
tation  is  utilized.  The  documentation  would  describe  the  problem,  proposed 
solutions,  and  the  one  solution  agreed  upon  by  the  contractors.  The  document 
would  be  filed  with  the  prime  contractor  for  future  reference.  The  final  means 
of  control  is  the  Interface  Control  Document  (ICD).  This  form  of  documentation 
is  the  most  formal  means  of  reporting  the  agreed  upon  design  interface  between 
associate's  subsystem  and  the  prime's  total  weapon  system.  The  ICD  is  reviewed 
by  the  prime  and  associate  contractors  and  by  the  customer  before  it  can  be 
approved  for  implementation.  Continuing  reviews  of  the  ICD  must  take  place  to 
insure  that  the  information  is  current,  and  periodic  meetings  must  be  held  to 
accomplish  necessary  updates  and  revisions.  By  utilizing  the  discussed  methods 
the  prime  and  associate  contractors  can  retain  the  needed  subsystem/ system  inter¬ 
face  design  configuration  control. 

2. 4. 3. 1.3  Subcontractor  Interfaces 

The  test  system  design  manager  or  his  representative  must  have  the  au¬ 
thority  to  deal  directly  with  the  aircraft  system  subcontractors  to  assure  the 
test  requirements  stated  in  the  procurement  specification  are  met. 

Test  design  personnel  must  be  closely  involved  with  the  subcontractor 
during  the  development  and  design  of  the  various  aircraft  subsystems  and  must 
attend  and  participate  in  the  aircraft  systems  design  reviews  with  the  sub¬ 
contractors  . 
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Past  experience  has  shown  that  in  many  cases  where  test  system  design  per¬ 
sonnel  participated  in  the  design  review  processes  with  the  subcontractor,  the 
quality  and  performance  of  the  test  interfaces  was  demonstrably  better  than 
where  the  test  design  personnel  were  not  involved.  In  those  cases  where  the 
test  design  personnel  were  not  involved,  or  lacked  the  authority  to  force  com¬ 
pliance  with  the  test  requirements,  the  aircraft  system  design  personnel  neg¬ 
lected  to  enforce  the  test  requirements  or  tended  to  reduce/compromise  the  test 
requirement  without  proper  coordination  with  the  test  design  group. 

Subcontractor  data  items  involving  the  test  system  implementation  must  be 
approved  or  rejected  by  the  test  system  manager.  Data  items  that  are  rejected 
must  be  coordinated  by  the  test  system  grot?)  (in  conjunction  with  the  system 
design  group)  with  the  vendor  via  the  assigned  buyer.  The  buyer  must  negotiate 
a  timely  data  resubmittal  date  with  the  subcontractor  in  order  to  support  design 
activities  and  schedules. 

Subcontractor  design  approval  by  the  aircraft  system  design  group  should 
not  be  granted  until  the  implementation  of  the  test  requirements  is  finalized 
and  approved  by  the  test  system  design  manager.  Past  experience  again  has 
shown  that  when  system  design  approval  was  given  before  test  implementation 
was  finalized,  the  test  requirements  were  often  compromised  by  the  vendor 
claiming  cost,  weight,  size,  and  schedule  inpacts  to  comply  with  the  test 
requirements.  As  a  result  the  test  requirements  were  often  reduced  by  the 
aircraft  system  design  group  thus  compromising  the  test  system. 

2. 4. 3. 2  Test  System  Design 

Control  of  the  design  of  the  onboard  test  system  is  almost  completely  an 
internal  function  of  the  test  system  design  group.  The  organization  and  man¬ 
agement  structure  recommended  in  paragraph  2. 4. 1.1  and  shown  in  figure  2-1  is 
structured  with  this  control  in  mind.  The  integration  subgroup  performs  the 
majority  of  the  control  tasks,  under  two  levels  of  management.  The  controls 
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are  primarily  concerned  with  changes  in  the  design  areas. of  hardware,  software, 
and  test  requirements  which  very  often  impact  each  other.  Coordination  of  such 
changes  between  the  three  subgroups  is  an  absolute  necessity,  regardless  of  the 
reasons  for  the  change  or  whether  or  not  the  change  was  the  result  of  outside 
influences  (.e.g.,  aircraft  system  changes,  weapon  system  configuration  change, 
customer  redirection,  etc.). 

2. 4. 3. 3  Test  System  Checkout 

Later  in  the  development  phase,  when  the  test  system  has  been  installed 
in  the  aircraft  and  the  weapon  system  has  been  released  from  the  control  of 
manufacturing,  post -installation  checkouts  must  be  accomplished  prior  to  first 
flight.  Preparation  of  checkout  procedures  and  specifications  are  normally 
the  responsibility  of  logistics,  but  extensive  coordination  must  take  place  to 
insure  that  the  test  system  is  properly  used.  Additionally,  if  these  checkouts 
reveal  anomalies,  the  test  system  design  group  must  analyze  the  problems  and 
make  the  determination,  with  the  help  of  associated  aircraft  system  design  per¬ 
sonnel,  as  to  whether  the  problem  is  caused  by  the  aircraft  system  or  the  test 
system. 

It  is  imperative  that  adequate  effort/priority  be  provided  in  resolving 
these  anomalies.  This  effort  may  also  require  the  support  of  the  flight  test 
checkout  personnel  in  taking  additional  measurements/data  and/or  running  extra 
tests  to  define  the  cause  of  the  problem  and  also  provide  the  necessary  data  to 
verify  or  redefine  the  test  requirements  and  subsystem  performance  requirements. 
This  effort  is  essential  in  order  to  provide  as  optimum  a  test  system  as  possible 
to  minimize  potential  false  indications  at  first  flight.  Past  experience  has 
revealed  that  when  unresolved  problems/false  indications  are  carried  over  for 
correction  subsequent  to  first  flight  additional  complicat ions/delays  are  en¬ 
countered.  Typically  after  first  flight  additional  analysis  effort  is  required 
to  provide  the  following: 
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.  Analysis  of  data  for  real-world  subsystem  performance 
for  the  design  group. 

.  Analysis  of  data  for  validation  of  failure  indications 
and  dispositioning. 

Validation  of  test  mechanization/limits  for  subsystem 
go/no-go  status. 

With  the  above  extra  efforts  on  the  test  system  designers  and  general 
lack  of  adequate  support  from  flight  test  personnel  due  to  their  maintenance 
workload  in  keeping  the  aircraft  in-flight  status,  the  test  system  problem 
resolutions  are  slow  in  coming.  Furthermore,  after  first  flight  a  new  group 
of  test  problems  may  arise  due  to  flight  condition  variables  which  may  cause 
different  test  system/subsystem  responses  than  expected,  thus  requiring 
additional  investigation  and  resolutions. 

2.5  SUNMARY 

Preliminary  considerations  which  may  not  be  directly  related  to  test 
hardware  or  software  are  covered  in  this  section.  A  baseline  philosophy 
and  approach  is  given  which  governs  the  development  and  content  of  succeeding 
sections  of  the  design  guide.  These  include  definitions,  assumptions,  limi¬ 
tations/restrictions,  performance  requirements,  and  organization,  management, 
and  control.  Not  only  do  these  considerations  affect  the  actions  and  efforts 
of  an  onboard  test  system  contractor,  but  also  influence  how  the  customer 
conducts  and  directs  the  overall  program. 


Section  3 

REQUIREMENTS  ANALYSIS  GUIDELINES 

3.1  EVALUATION  OF  FUNCTIONAL  REQUIREMENTS 

The  first  step  toward  establishing  a  design  for  an  onboard  test  system 
is  the  determination  of  what  the  system  is  supposed  to  accomplish.  Genera] ly, 
the  procuring  agency  (the  customer)  has  outlined  the  performance  requirements 
in  the  Request  for  Proposal  (RFP),  the  System  Specification,  and  the  I'evelop- 
ment  Specification  in  sufficient  detail  to  understand  what  is  wanted,  but  too 
often  that  is  not  the  case.  A  failure  on  the  part  of  the  contractor  to  ask 
enough  of  the  proper  questions  results  then,  in  a  lack  of  understanding  which 
usually  does  not  become  apparent  until  later  in  the  development  phase,  whereby 
considerable  effort  may  have  to  be  redirected  at  the  expense  of  time  and  money. 
In  the  light  of  this  distinct  possibility,  special  attention  should  be  given 
to  a  careful  and  thorough  evaluation  of  all  functional  requirements,  both  for 
the  onboard  test  system  and  for  those  systems,  subsystems,  or  equipments  which 
are  to  be  tested.  This  evaluation  should  be  for  the  express  purpose  of  estab¬ 
lishing  agreement  between  the  customer  and  the  contractor  on  every  specific 
detail  to  eliminate  the  chance  for  erroneous  assumptions,  ambiguities,  incom¬ 
plete  or  unclear  definitions,  and  vague  wording. 

Figure  3-1  shows  the  events  and  the  sequence  of  events  starting  with  the 
conceptual  phase  in  the  development  of  an  onboard  test  system  and  ending  with 
the  prequalification  testing  of  the  test  system.  Activities  between  beginning 
and  end  are  identified  by  a  description  title,  areas  of  responsibility  for  each 
activity  is  designated,  and  design  guide  paragraph  numbers  relating  to  certain 
activities  are  referenced.  The  designators  for  responsibility  areas  are  as 
follows : 

©  Air  Force  (r"Stomer) 

©  Prospective  Prime  Contractors 

(?)  Prime  Contractor  (Onboard  Test  System  Design  Group) 
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(T)  Prime  Contractor  (Aircraft  Subsystems  Design  Group) . 

©  Subcontractor  (Onboard  Test  System). 

©  Subcontractor  (Aircraft  Subsystem) . 

©  Associate  Contractor  (Aircraft  Subsystem) 

3.1.1  T'EST  SYSTEM 

Those  functional  test  requirements  pertaining  to  the  test  system  include 
detection  assurance,  isolation  certainty,  availability,  maintainability,  false 
indications,  and  the  various  contraints  which  may  be  imposed  and  which  impact 
the  performance  of  the  test  system. 


3. 1.1.1  Detection  Assurance 

The  first  function  of  a  test  system  is  the  detection  of  failures.  A 
measure  of  the  capability  of  the  system  to  accomplish  this  function  is  the 
"detection  assurance,"  defined  in  Section  2  as  the  probability  that  a  failure 
of  a  system,  subsystem,  or  equipment  under  test  will  be  detected  and  displayed 
by  the  test  system.  This  probability  is  normally  expressed  as  a  percentage 
and  is  computed  as  follows: 
i  =  m 

Z  A.  x  100  A,  x  100  A,  x  100 

l  d  d 

D  =i=l _ _  _ =  _ 

i  =  n 

Z  A.  A,  +  A  A 

i  d  u 

i  =  1 

where: 

D  =  percent  detection  assurance 

A^  =  failure  rate  of  ith  failure  mode  (failures  per  hour) 

A^  =  summation  of  all  failure  inodes  detected  by  the  test 
system  (failures  per  hour) 
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Xu  =  summation  of  all  failure  modes  undetected  by  the  test 
system  (failures  per  hour) 

X  =  summation  of  all  failure  modes,  both  detected  and 
undetected  (failures  per  hour) 
m  =  the  number  of  failure  modes  detected 
n  =  the  total  of  failure  modes  of  the  item  tested 

This  method  of  computation  takes  into  account  the  relative  failure  rates 
of  the  various  failure  modes  inherent  in  a  system,  subsystem,  or  equipment 
and  gives  greater  credit  to  the  detection  of  a  failure  of  frequent  occurrence 
than  it  does  to  a  failure  which  rarely  occurs.  The  failure  rates  are,  of 
course,  not  definite  but  are  predictable  and  as  such  result  in  a  figure  of 
merit  (percent  detection  assurance)  which  is  nothing  more  nor  less  than  a 
probability.  Therefore,  the  percent  detection  assurance  cannot  necessarily 
be  proven  to  be  a  particular  value  at  any  given  time,  but  must  be  evaluated 
only  after  a  relatively  long  period  of  operation  has  taken  place  in  an  envi¬ 
ronment  typical  of  that  for  which  the  test  system  was  designed.  Nevertheless, 
the  probability  figure  obtained  by  the  computation  above  is  by  far  the  most 
reliable  method  of  providing  an  initial  insight  into  what  must  be  provided 
in  the  way  of  testing  to  achieve  a  design  which  is  worthy  of  consideration. 

The  source  of  the  failure  rates  necessary  for  the  calculation  of  detection 
assurance  is  the  FMEA,  which  must  be  available  for  each  LRU  in  each  system, 
subsystem,  or  equipment  comprising  the  overall  weapon  system.  Usually,  the 
requirement  for  a  given  detection  assurance  is  stated  on  the  basis  of  the 
entire  weapon  system,  but  it  can  be  stipulated  as  applying  to  each  system, 
subsystem,  or  equipment.  This  point  must  be  clearly  established  since  the 
emphasis  on  testing  one  system  versus  another  system  can  be  a  big  factor  in 
influencing  the  test  system  design  to  meet  the  detection  assurance  requirement. 
Although  the  selection  of  test  points  and  tests  will  be  primarily  determined 
by  failure  rates,  other  factors  enter  into  a  final  selection.  These  factors 
will  be  covered  in  more  detail  later,  but  for  now  the  main  objective  is  in 
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arriving  at  a  combination  of  tests  which  provide  an  acceptable  detection 
assurance  figure.  This  initial  figure  will  then  provide  a  basis  for  trade¬ 
offs  and  alternative  approaches. 

3. 1.1. 2  Isolation  Certainty 

The  second  and  probably  most  important  function  of  a  test  system  is 
the  isolation  of  a  detected  failure  to  a  particular  LRU.  A  measure  of  the 
capability  of  the  system  to  accomplish  this  function  is  the  "isolation  cer¬ 
tainty,"  defined  in  Section  2  as  the  probability  that  a  failure  of  the  system, 
subsystem,  or  equipment  which  has  been  detected  by  the  test  system  can  be 
correctly  identified  and  displayed  as  being  located  in  a  given  LRU.  This 
probability  is  normally  expressed  as  a  percentage  and  is  computed  as  follows: 
i  =  P 

1  XiLRU  x  100  XILRU  X  100  XILRU  x  100 

I  =  i  =  1 _ =  _ =  _ 

i  *  m 

1  XiLRU  XILRU  +  XULRU  X  LRU 

i  =  1 

where : 

I  =  percent  isolation  certainty 

XiLRU  =  failure  rate  of  ith  LRU  (failures  per  hour) 

XILRU  =  simulation  of  failure  rates  for  all  LRU's  isolated  by  the 
test  system  (failure  per  hour) 

XULRU  =  simulation  of  failure  rates  for  all  LRU's  not  isolated 
by  the  test  system 

X  LRU  =  simulation  of  failure  rates  for  all  LRU's  both  isolated 
and  not  isolated  by  the  test  system  (failures  per  hour) 
m  =  the  number  of  failure  modes  detected 
p  =  the  number  of  failure  modes  isolated 


This  method  of  computation  takes  into  account  the  relative  failure  rates 
of  the  various  failure  modes  inherent  in  the  various  LRU's,  in  much  the  same 
manner  as  was  done  in  the  computation  of  detection  assurance.  Thus,  more  over¬ 
all  credit  is  given  for  the  isolation  of  an  LRU  with  a  high  failure  rate  than 
is  given  for  isolation  of  an  LRU  which  rarely  fails.  Again,  the  FMEA  provides 
the  necessary  figures  for  calculating  percent  isolation  certainty  but  one  im¬ 
portant  fact  must  be  kept  in  mind.  That  fact  is  that  only  failures  which  have 
been  detected  can  be  isolated.  In  other  words,  the  computation  of  isolation 
certainty  cannot  involve  the  failure  modes  not  included  as  detectable  as  deter¬ 
mined  by  the  computation  of  the  detectable  assurance.  It  follows  then  that 
isolation  certainty  can  only  be  determined  after  detection  assurance  has  been 
calculated. 

Credit  for  isolation  of  a  failure  of  an  LRU  involves  still  another  factor 
-  that  of  uniqueness  of  isolation.  Ideally,  each  isolation  to  an  LRU  would  be 
unique.  This  is,  100  percent  of  the  detected  failure  modes  would  be  associated 
with  one,  and  only  one,  ilentifiable  LRU.  More  realistically,  however,  the  sit¬ 
uation  occurs  where  such  positive  identification  is  not  practically  possible 
and  ambiguity  of  isolation  exists.  A  failure  of  an  LRU  causes  a  system/sub¬ 
system  failure  mode.  This  failure  mode  may  be  detected  at  a  point  other  than 
at  the  actual  failure  point.  Several  different  failures  located  in  different 
LRU's  may  cause  the  same  failure  mode.  By  utilizing  additional  test  signals, 
a  failure  may  be  located  to  a  particular  LRU  (unique  isolation)  but  in  some 
cases  it  is  possible  or  feasible  only  to  locate  a  failure  to  within  a  choice 
of  the  two  or  more  most  likely  LRU's  (ambiguous  isolation).  In  those  cases 
of  ambiguous  isolation,  credit  taken  for  isolation  can  only  be  partial  since 
isolation  to  a  single  identifiable  LRU  is  not  made  (see  definition  of  fault 
isolation,  paragraph  2. 2. 2. 2. 7).  The  method  of  determining  the  degree  of  is¬ 
olation  creditable  in  the  computation  of  percent  certainty  is  based  on  failure 
rates.  The  maximum  failure  rate  is  determined  for  that  failure  in  each  LRU  which 
can  cause  a  particular  system/subsystem  failure  mode;  the  failure  rates  are  sunined 
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for  the  group;  each  failure  rate  divided  by  the  group  sum  gives  the  percentage 
of  that  failure  rate  to  be  used  in  computing  the  overall  system/ subsystem  iso¬ 
lation  certainty. 

For  example,  if  for  a  given  system/ sub system  failure  mode  (failure  mode 
X)  the  failure  can  be  isolated  only  to  a  group  of  three  LRU's  with  failure 
rates  of  30  failures/million  hours,  20  failures/million  hours,  and  10  failures/ 
million  hours  respectively,  the  determination  of  partial  isolation  credit  is 
made  as  follow: 

X1+A^+A,=30+20+10=60  failures/106  hours 
1  2  3  - w - 


1P  -  mt  *  x 

=  30 

x  30  =  15  failures/106  hours 

60 

2P  =  X  2  x  X 

2  =  20 

x  20  =  6.67  failures/106  hours 

60 

60 

3P  =  X  3  x  X 

3-10 

x  10  =  1.67  failures/106  hours 

60 

60 

where: 


1  =  Failure  rate  (associated  with  failure  mode  X)  of 

first  LRU  in  isolated  group 

2  =  Failure  rate  (associated  with  failure  mode  X)  of 

second  LRU  in  isolated  group 

3  =  Failure  rate  (associated  with  failure  mode  X)  of 

third  LRU  in  isolated  group 

IP  =  Creditable  failure  rate  of  first  LRU  in  isolated  group 
2P  =  Creditable  failure  rate  of  second  LRU  in  isolated  group 
3P  =  Creditable  failure  rate  of  third  LRU  in  isolated  group 
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Use  of  these  creditable  failure  rates  in  the  computation  of  a  system/ subsystem 
isolation  certainty  is  as  shown  in  the  following  example: 

Given:  A  system  comprised  of  10  LRU's  with  failure  rates  as  follows: 

*1,  *4,  *8  =  30  failures/million  hours 

*2,  *5  =  20  failures/million  hours 

*9,  *10  =  15  failures/million  hours 

*3,  *6,  *7  =  10  failures/million  hours 

LRU's  1,  2,  and  3  are  isolated  ambiguously 

LRU's  4  through  10  are  isolated  uniquely  • 

I  =  E  X.  EX. 

_ ll  =  _ i 

E  A?  l  XT 

*lp  =  15  failures/million  hours 
*2p  =6.67  failures/million  hours 

*3p  =  1.67  failures/million  hours 

I  =  C23.34)  +  (130)  153.34  = 

190  190 


see  above 


0.807  (80.7  percent) 


3.1.1. 3  Availability 

Although  availability  is  primarily  a  requirement  imposed  on  the  overall 
weapon  system,  it  is  a  definite  consideration  in  the  design  of  an  onboard 
test  system.  Availability  of  a  weapon  system  is  a  complex  function  of  equip¬ 
ment  reliability,  corrective  maintenance  time,  mission  time,  duty  cycle, 
functional  performance  threshold,  and  failure  detectability.  For  the  purpose 
of  quantification,  availability  can  be  expressed  as: 

A 


P„  +  DM  (1 
tm  tr 


Ptm> 
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where : 

A  *  Availability  (probability  that  the  weapon  system  will  be  available 
in  an  operationally  acceptable  condition  at  any  time). 

=  Probability  that  the  weapon  system  will  be  operational  (no  failures) 
for  the  duration  of  time  t  (a  function  of  reliability). 

M  r  =  Probability  that  a  detected  failure  can  be  repaired  in  time  t^ 

(maintainability) . 

t  =  Mission  time, 
m 

D  =  Probability  that  a  failure  will  be  detected  (detection  assurance) . 

It  is  obvious  that  the  basic  factors  in  the  determination  of  availability 
are  reliability,  maintainability,  and  detection  assurance.  Thus,  the  attain¬ 
ment  of  a  particular  availabilty  is  entirely  dependent  upon  these  three  vari¬ 
ables.  Of  the  three,  reliability  is  the  least  likely  to  be  improved  to  any 
appreciable  extent. 

Maintainability  is  actually  affected  by  two  areas  of  influence  -  weapon 
system  design  and  test  system  design.  Such  weapon  system  features  as  LRU 
accessibility,  weight,  volume,  and  complexity  can  be  controlled  positively 
through  careful  planning  and  coordination  but  generally  are  limited  as  candi¬ 
dates  for  improving  availability  because  of  operational  considerations.  How¬ 
ever,  test  system  design  can  substantially  impact  maintainability  through 
improved  fault  isolation  which  reduces  time  necessary  for  troubleshooting, 
and  through  improved  and  more  thorough  testing  which  not  only  speeds  up  re¬ 
verification  testing,  but  reduces  repetitive  maintanence  resulting  from  re¬ 
moval  and  replacement  of  LRU’s  erroneously  identified  as  failed.  Thus,  the 
isolation  certainty  aspect  of  the  test  system  weighs  heavily  in  determining 
whether  or  not  a  weapon  system  can  meet  a  particular  availability  goal.  The 
primary  aspect  of  the  test  system  (detection  assurance)  is  the  third  basic 
factor  influencing  availability  directly.  As  can  be  seen,  the  greater  the 
proportion  of  failures  de  *cted  immediately  the  sooner  the  problem  can  be 
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addressed  and  the  sooner  corrective  maintenance  can  be  accomplished.  An 
example  of  the  application  of  these  quantified  factors  is  given  in  the  prob¬ 
lem  stated  below: 

GIVEN:  A  weapon  system  is  required  to  meet  an  availability 
requirement  of  95  percent,  with  an  average  mission 
time  of  10  hours  and  a  maximum  turnaround  time  of 
3  hours.  The  corresponding  probability  of  opera¬ 
tional  integrity  for  this  mission  time  is  80  percent 
and  the  probability  of  maintenance  success  for  the 
turnaround  time  is  80  percent. 

FIND:  The  minimum  detection  assurance  that  must  be  provided 

by  an  onboard  test  system  in  order  to  achieve  the 
availability  goal  under  the  given  conditions. 

SOLUTION: 


A  =  p  +  DM. 
tm  tr 


(1  -  P  1 
v  tm 


D  =  j-j - Ti - 55-  =  0,95  -  0.80  =  005 

tr  U  '  tin  0.80  (1  -  0.80)  0.16 

D  =  0.94  (94  percent) 

It  should  be  noted  that  the  above  calculation  does  not  directly  show  the 
influence  of  the  isolation  certainty  of  the  test  system  on  the  maintenance 
figure,  although  it  is  reflected  in  the  80  percent  probability  given  in  the 
problem.  This  influence  will  be  discussed  in  the  following  paragraph  on 
maintainability. 


3. 1.1. 4  Maintainabilit) 


It  is  apparent  that  maintainability  is  the  area  which  can  be  most  improved 


by  a  well-designed  onboard  test  system.  Time  is  the  all-important  factor  in 
effective  maintenance  since  an  overall  goal  is  the  reduction  of  weapon  system 


downtime.  Consequently,  the  onboard  test  system  must  contribute  to  time  savings 


in  those  maintenance  tasks  where  testing  is  involved.  Reduction  of  time  in 
detecting  failures  and  in  locating  those  failures  without  sacrificing  accu¬ 
racy  or  completeness  of  testing  is  the  basic  task. 

Using  the  system  requirements  given  in  the  example  of  paragraph  3. 1.1. 3 
(Availability) ,  the  relationship  between  the  various  factors  affecting  main¬ 
tainability  and  those  affected  by  maintainability  can  be  shown.  If  only  the 
correction  of  failures  is  considered  in  the  maintenance  task  (ignoring  such 
things  as  replacement  of  expendables  and  administration  time) ,  Mean  Corrective 
Maintenance  Time  (M  )  can  be  obtained  by  using  activity  categories  and  asso¬ 
ciated  times  as  given  in  MIL-HDBK-472: 

Activity  Categories  Mean  Time  (Hours) 


I  =  100% _ I  =  0% 

Preparation  Time 

Gaining  Access  0.275  0.275 

Malfunction  Verification 

(No  observations  or  tests  necessary  0.000  0.000 

after  initial  failure  report) 

Fault  Location 

Interpreting  Displays  0  0.333 

Interpreting  Meter  Readings  0  0.089 

Switching/Substituting  Units  0  0.221 

Consulting  Tech  Orders  0  0.240 

Conferring  With  Tech  Representatives/Maintenance  0  0.466 

Personnel 

Performing  Standard  Test  Problems  0  0.582 

Using  Special  Test  Equipment  0  0.320 

Part  Procurement 

Obtain  Replacement  from  Shop,  etc.  0.012  0.012 
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Activity  Categories  (Cont)  Mean  Time  (Hours) 


I  =  100% _ I  =  0% 

Repair 

Remove/Replace  Units  0.239  0.239 

Final  Malfunction  Test 

Observing  Indication  Only  0.039  0.039 

Total  Corrective  Time  0.565  2.816 


Maintainability  can  be  expressed  using  the  exponential  approximation: 

H-  1  -  €  jj-1 

ct 

where: 

tf  =  repair  time  for  which  M  is  estimated 

M  ^  =  mean  corrective  maintenance  time 
ct 

Applying  this  equation: 

-3 _  =  1-e  -  5.3  =  1  -  0.005 

M  =  1-e  0.565 

M  *  0.995  =  99.5% 

This,  therefore,  shows  that  a  test  system  with  a  detection  assurance  of 
95  percent  and  an  isolation  certainty  of  100  percent  will  permit  the  maintain¬ 
ability  requirement  of  80  percent  to  be  easily  exceeded  for  a  maximum  allowable 
repair  time  of  3  hours.  However,  since  it  is  highly  unlikely  that  an  I  of  100 
percent  would  be  practically  attainable,  further  computations  should  be  made 
to  determine  what  a  more  feasible  value  of  I  (75  percent)  would  permit. 

The  worst  case  (1=0  percent)  fault  location  time  was  found  to  be  2.251 
hours,  so  the  fault  location  time  (tj)  for  I  =  75  percent  would  be: 
tj  =  (2.251)  (1-1)  =  (2.251)  (1-0.75)  =  0.563  hours 

and  the  total  corrective  time  would  be  increased  by  this  increased  isolation 
time: 

M  .  =  0.565  +  0.563  =  1.128  hours 
ct 
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Then: 


-  2.66 


M  =  1  -  e  -  =  1  -  e  r-  -x  =  1  -  e 

m  ^  1.128 

ct 

=  1  -  0.07 
=  0.93  (93%) 

Thus,  a  reduction  of  isolation  certainty  to  the  value  of  75  percent  did 
not  materially  endanger  the  ability  of  the  weapon  system  to  meet  (actually  to 
exceed)  the  maintainability  requirement.  Furthermore,  the  results  of  compu¬ 
tations  give  rise  to  a  need  for  further  investigation  into  a  more  compatible 
set  of  requirements.  The  impact  of  several  combinations  of  detection  assurance 
and  isolation  certainty  for  an  onboard  test  system  is  shown  in  Table  III -1  and 
Figure  3-2.  The  effect  of  isolation  certainty  on  the  maintainability  figure 
for  a  given  set  of  repair  times  is  shown  in  Figure  3-3. 

3. 1.1. 5  False  Indications 

Typically,  the  requirement  pertaining  to  false  indications  will  be  stated 
as  a  percentage  not  to  be  exceeded.  Often  this  is  taken  to  mean  that  of  a 
total  number  of  indications  occurring,  a  certain  percentage  is  expected  (or 
is  allowed)  to  be  erroneous.  Without  further  qualifications,  such  as  the 
period  of  time  over  which  indications  are  to  be  evaluated  for  correctness, 
this  requirement  cannot  be  taken  seriously  or  treated  with  concern.  Further¬ 
more,  if  the  definition  of  false  indications  (as  given  in  Section  2) ,  is  ad¬ 
hered  to,  an  accounting  must  be  made  not  only  of  indications  occurring  erron¬ 
eously,  but  of  these  instances  where  indications  did  not  occur  when  they  should 
have  occurred.  Furthermore,  intermittent  failure  indications  must  also  be 
included,  even  though  the  indication  does  not  persist  over  any  particular 
length  of  time.  Each  such  indication  must  be  evaluated  and  identified  as 
either  a  true  failure  (denoting  an  abnormal  situation)  or  a  false  indication. 
Additionally,  a  more  accurate  evaluation  of  the  ability  of  a  test  system  to 
display  a  correct  representation  of  system,  subsystem,  or  equipment  health 
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TABLE  III-l 

IMPACT  OF  ONBOARD  TEST  SYSTEM  VARIABLES 
ON  WEAPON  SYSTEM  REQUIREMENTS 
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should  take  into  account  all  the  possible  indications  as  a  basis  for  compar¬ 
ison,  and  not  just  those  indications  which  actually  occur. 

Thus,  the  necessity  for  some  method  of  record-keeping  involving  false 
indication  rate  is  to  be  made.  The  source  of  the  information  to  be  recorded 
for  non-indicated  failures  must  rely  on  failure  reports  and  other  maintenance 
records  not  ordinarily  associated  with  the  test  system,  but  even  then  such 
records  must  be  examined  for  applicability  to  the  evaluation.  For  instance, 
if  a  failure  is  reported  which  was  not  indicated  by  the  test  system,  it  must 
be  determined  whether  or  not  that  particular  failure  was  supposed  to  have  been 
detected  by  the  test  system.  Naturally,  if  the  failure  was  not  considered  or 
included  in  the  test  logic,  it  should  not  be  counted  as  a  false  indication  in 
the  computation  of  false  indication  rate. 

An  example  of  the  method  of  computing  false  indication  rate  is  given 
below. 

The  B-l  aircraft  onboard  test  system  has  the  capability  to  output  and 
display  1,250  different  failure  indications.  Flight  test  data  obtained  from 
one  aircraft  over  60  flights  revealed  that  the  number  of  false  indications  per 
flight  varied  from  a  high  of  28  to  a  low  of  3,  discounting  two  flights  where 
no  indications  were  recorded  due  to  equipment  problems.  On  a  single- flight 
basis  the  maximum  false  indication  rate  would  be: 

F.I.  rate  =  28 _ =  0.0224  =  2.24%  (maximum) 

1,250 

Taken  over  the  entire  60  flights,  the  data  shows  a  total  of  793  false 
indications.  Using  only  the  58  flights  for  which  data  was  actually  recorded, 
the  average  number  of  false  indications  per  flight  is  13.7.  Thus,  the  average 
false  indication  rate  is: 

F.I.  rate  *  13.7  =  0.011  =  1.1% 

1,250 
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It  is  obvious  that  the  F.I.  rate  will  vary  depending  on  the  number  of 
flights  considered  and  the  time  period  covered.  Since  fixes  will  be  made 
along  the  way  to  eliminate  false  indications,  calculations  of  F.I.  rate  which 
include  the  most  recent  data  should  reflect  the  improvements  in  a  lower  rate. 
In  addition,  some  failures  not  previously  considered  or  included  in  the  test 
logic  because  of  predicted  low  failure  rates  exhibit  failure  rates  in  actual 
operation  high  enough  to  necessitate  their  inclusion.  These  additions,  would, 
of  course,  affect  the  F.I.  calculations  and  lower  the  F.I.  rate  even  further. 

3. 1.1. 6  Constraints 

Depending  upon  the  type  of  aircraft  or  weapon  system  on  which  the  onboard 
test  system  is  to  be  installed,  and  the  basic  mission  assignments,  the  test 
system  will  be  subject  to  certain  functional  constraints.  These  constraints 
will  limit  the  choice  of  tests,  the  methods  of  testing,  and  the  degree  of 
automaticity.  Requirements  involving  interference/non-interference  testing, 
failure  switching,  radiation  silence,  and  degree  of  operation  participation 
are  some  of  the  constraints  which  may  be  encountered. 

3. 1.1. 6.1  Interference /Non- Interference  Testing 

Interference  testing,  whereby  normal  operation  of  the  unit  under  test  is 
disrupted,  should  be  avoided.  Exception  can  be  made  only  if  such  testing  is 
limited  to  an  environment  where  the  system  under  test  is  active  but  not  oper¬ 
ating  under  weapon  system  mission  conditions,  such  as  on  the  ground.  Use  of 
input  test  stimuli  in  such  tests  should  be  carefully  controlled  to  avoid  the 
possibility  of  inadvertent  application,  and  subsequent  interference,  in  flight 

Consideration  must  also  be  given  to  incorporation  of  safety  features  for 
the  ground  tests  whereby  movement  of  surfaces,  doors,  actuators,  etc.,  is 
initiated  and  can  present  conditions  possibly  harmful  to  maintenance  personnel 


3. 1.1. 6. 2  Failure  Switching 

A  constraint  that  may  be  imposed  is  the  prohibition  of  the  automatic 
initiation  or  control  of  switching  of  subsystems,  functions,  or  modes  by 
the  onboard  test  system.  However,  this  does  not  prevent  the  test  system 
from  monitoring  such  operations  employed  in  fail-safe  schemes  by  system, 
subsystem,  or  equipment  designers. 

3. 1.1. 6. 3  Radiation  Silence 

The  onboard  test  system  may  be  required  to  be  capable  of  evaluating  and 
testing  system  performance  when  radiation  systems  are  either  radiating  or 
observing  radiation  silence. 

Depending  upon  the  type  of  weapon  system  and  the  type  or  types  or 
missions  normally  performed,  it  may  be  important  to  know  at  all  times  the 
status  of  those  equipments  which  radiate.  These  include  not  only  commu¬ 
nications  equipment,  but  also  radar  used  for  navigation  and  offensive/defen- 
sive  purposes.  It  is  possible  that  a  particular  mission  may  require  radiation 
silence  for  a  relatively  long  period  of  time,  after  which  the  radiation  equip¬ 
ment  is  necessary  for  successful  completion  of  the  mission.  Therefore,  if  a 
failure  of  any  of  this  equipment  occurs  during  the  radiation  silence  period, 
it  would  be  imperative  to  be  aware  of  this  fact  immediately  to  allow  an  in¬ 
flight  assessment  of  the  remaining  capabilities  and  impact  on  the  mission. 

3. 1.1. 6. 4  Operator  Participation 

A  requirement  for  automaticity  may  simply  specify  that  the  test  functions 
shall  minimize  manual  or  semi -manual  operations.  This  usually  includes  inter¬ 
pretation  of  displayed  test  results  by  the  test  system  operator  through  the 
use  of  a  manual,  code  sheet,  or  other  documentation. 

This  requirement  is  based  on  the  premise  that  the  introduction  of  human 
intervention  (manual  operation/operator  interpretation)  not  only  increases 
the  time  for  testing,  but  also  increases  the  possibility  of  error.  In  some 
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cases,  tests  involving  operator  participation  are  made  necessary  because  the 
disadvantages  are  outweighed  by  the  impract icality/ cost  of  implementing  auto- 
maticity.  Thus,  the  requirement  cannot  be  stated  quantitatively,  but  is 
broadly  stated  to  allow  the  designer  to  exercise  his  judgement  in  the  selec¬ 
tion  of  the  proper  degree  of  operator  participation.  It  is  expected  that  his 
judgement  will  be  influenced  by  the  impact  on  other  more  specific  requirements 
such  as  availability  and  maintainability. 

3.1.2  SYSTEM  UNDER  TEST 

The  development  and  implementation  of  adequate  test  requirements  into  the 
system  under  test  requires  complete  definition  of  functional  requirements  in¬ 
cluding  sufficient  data  covering  availability,  maintainability,  and  perfor¬ 
mance.  The  inter-relationship  of  these  factors  determine  what  type  of  onboard 
testing  is  required  and  at  what  time  intervals  testing  should  be  done.  The 
following  will  discuss  these  factors  and  their  relationship  to  onboard  test 
requirements  development. 

3. 1.2.1  Availability 

Aircraft  availability  time  is  one  factor  of  the  maintenance  concept  which 
is  directly  affected  by  onboard  testing  of  the  subsystems.  When  developing 
onboard  test  requirements  there  should  be  priority  given  to  the  study  of  the 
effects  to  aircraft  availability. 

The  availability  requirement  for  the  system  under  test  would  be  calcu¬ 
lated  in  accordance  with  the  method  defined  in  Paragraph  3. 1.1. 3. 

3. 1.2. 2  Maintainability 

Evaluation  of  the  maintainability  requirements  impact  on  the  system  under 
test  requires  careful  consideration.  This  involves  an  assessment  of  the  qual¬ 
itative  and  quantitative  maintainability  requirements  together  with  a  thorough 
understanding  of  its  relationship  to  the  system  availability  requirements  and 


3-20 


the  test  system's  contribution  to  meeting  these  requirements.  Review  of  the 
system's  design  configuration,  installation,  and  the  mechanization  of  the 
test  system  components  into  the  system  are  all  essential  factors  in  this 
evaluation.  Computat ions  for  verification  of  the  maintainability  require¬ 
ments  shall  utilize  the  method  defined  in  paragraph  3. 1.1. 4. 

3. 1.2. 3  Performance 

System  performance  can  be  defined  as  that  system's  capability  to  prop¬ 
erly  execute  those  specific  design  characteristics  as  prescribed  by  the 
procurement  specification.  An  evaluation  of  the  system's  performance  re¬ 
quirements  is  essential  to  insure  that  a  clear  definition  of  these  require¬ 
ments  exists  and  that  they  can  be  implemented.  This  includes  a  functional 
understanding  of  the  system  and  the  ability  to  incorporate  the  necessary 
test  requirements  into  the  system. 

3. 1.2. 3.1  Parameter  Characteristics 

In  reviewing  the  functional  requirements  of  the  system  under  test,  partic¬ 
ular  attention  should  be  devoted  to  the  characteristics  of  the  parameters. 

Each  of  these  parameters  requires  analysis  for  their  criticality  in  system 
operation  and  their  compatibility  with  the  test  system. 

An  example  of  this  situation  can  be  seen  in  the  engine  test  development 
for  the  B-l  CITS.  During  examination  of  failure  modes  for  engine  testing,  it 
was  found  that  during  repetitive  stalls  the  compressor  discharge  pressure 
oscillates  at  about  four  times  per  second.  To  monitor  such  a  signal  the  sample 
rate  would  have  to  be  40  times  per  second,  which  was  considered  impractical  for 
the  CITS  system  which  had  a  maximum  sample  rate  of  16  per  second.  However, 
further  analysis  revealed  that  the  failure  rate  of  the  repetitive  stall  failure 
mode  was  small  compared  to  the  complexity  of  monitoring  this  condition.  In 
addition,  this  failure  condition  does  progress  into  a  fixed  stall  failure  mode 
which  is  detectable  and  the  parameter  can  be  adequately  monitored  thus 
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satisfying  the  detection/isolation  requirements. 

Considering  the  example  given,  parameter  characteristics  are  very  impor¬ 
tant  when  deciding  what  failure  modes  to  test,  and  what  signals  should  be  mon¬ 
itored  for  detection  of  those  system  malfunctions. 

3.1.2. 3.1.1  Normal.  The  normal  characteristics  of  each  operational  para¬ 
meter  should  be  evaluated  for  its  normal  range,  response  rate,  stability, 
repeatability,  accuracy,  and  how  critical  it  is  to  system  operation.  The 
review  should  also  include  an  analysis  of  the  parameters  during  non -normal 
conditions  for  assessment  as  a  test  parameter. 

An  example  of  this  type  of  analysis  can  be  cited  from  the  B-l  CITS 
development.  Analysis  of  the  fire  protection  system  indicated  that  the 
sensing  element  parameter  was  essential  to  system  performance  and  should  be 
monitored  by  the  test  system.  However,  in  evaluating  the  voltage  levels  of 
this  analog  signal  it  was  determined  that  overlaps  existed  through  the  stand¬ 
by/fire/short  stages  of  operation,  thus  appearing  that  ambiguous  indications 
were  possible.  However,  additional  analysis  revealed  that  by  using  additional 
status  discretes  for  the  fire  and  short  conditions,  the  parameter  was  useful 
in  the  testing  of  the  fire  protection  system.  It  is  seen  by  this  example, 
that  the  study  of  the  normal  characteristics  of  the  test  signals  is  essential 
in  determining  a  proper  onboard  test  mechanization. 

3. 1.2. 3. 1.1.1  Electrical.  The  system's  electrical  extemal/internal  inter¬ 
faces  for  input/output  signals  should  be  assessed  for  their  compliance  with 
the  applicable  requirements  for  their  respective  impact  on  system  performance. 
This  review  should  include  supply  voltages,  signal  types,  (serial  digital, 
discrete,  and  analogj ,  together  with  theiT  voltage  ranges,  currents,  percent 
regulation,  transient,  and  noise  rejection  characteristics. 
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3. 1.2. 3. 1.1. 2  Mechanical.  In  evaluating  the  functional  requirement  for  the 
system  under  test  there  may  be  mechanical  portions  that  must  be  analyzed  for 
their  design  performance  and  assessed  as  possible  candidates  for  testing. 

These  mechanical  aspects  may  be  grouped  into  the  following  categories: 

A.  Position  type  functions  which  measure  linear  or  angular  direction. 

B.  Rate  functions  that  cover  acceleration,  vibration,  and  flow. 

C.  Pressure  functions. 

D.  Temperature  functions. 

E.  Mechanical  states  covering:  open/closed;  ext ended/ retracted; 
up/down;  in/out;  and  left/right. 

F.  Electrical  states  covering:  singular  on/off  functions  or 
composite  on/off  type  patterns. 

Each  of  the  above  parameter  types,  as  applicable,  must  be  weighed  for  its 
relationship  to  system  performance,  normal/failure  signature  pattern,  and  abil¬ 
ity  to  be  monitored  by  the  test  system.  Evaluation  should  cover  the  parameter' 
basic  stability,  repeatability,  accuracy,  range,  sensitivity,  and  working  envi¬ 
ronment.  As  these  parameters  are  analyzed  the  decision  to  monitor  them  as  test 
parameters  must  be  made  concurrent  with  system  design  in  order  to  effect  an 
optimum  system/test  system  configuration  in  lieu  of  a  costly  ineffective  add¬ 
on  test  system. 

3.2  SPECIFICATION  OF  FUNCTIONAL  REQUIREMENTS  FOR  PROCUREMENT 

After  the  prime  contractor  has  evaluated  the  customer's  requirements 
sufficiently  to  understand  the  customer’s  needs,  appropriate  requirements 
must  be  established  and  communicated  to  the  subcontractors.  The  basic  means 
by  which  these  requirements  are  transmitted  is  the  procurement  specification. 
The  scope  of  these  procurement  specifications  may  range  from  single  LRU’s  to 
complete  systems.  These  subparagraphs  deal  with  the  types  of  requirements 
which  should  be  considered  as  functional  requirements  are  established  for  the 
procurement  of  both  the  test  system  and  the  systems  under  test. 
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As  an  example  of  the  format  and  content  of  a  typical  specification, 
refer  to  Appendix  A. 

3.2.1  TEST  SYSTEM 

The  test  system  consists  of  onboard  hardware  and  software  which  operate 
together  for  the  purpose  of  performance  monitoring,  fault  detection,  and 
fault  isolation.  The  basic  functions  of  the  onboard  test  system  hardware  are 
to  acquire  test  signals,  process  these  signals,  and  display  the  results  to 
flight  and  ground  crews.  In  addition  to  these  real-time  functions,  test 
results  in  hardcopy  printer  form  as  well  as  continuous  signal  recording  may 
be  required  for  ground  maintenance. 

From  the  standpoint  of  procurement,  the  .est  system  may  be  procured  with 
a  single  specification  or  each  LRU  may  be  procured  individually.  In  either 
case,  specification  requirements  must  be  established  by  the  contractor  such 
that  when  the  procured  test  system  is  integrated  with  the  systems  under  test, 
the  customer's  original  requirements  for  an  onboard  test  system  will  be  met. 
In  the  development  of  the  test  system  hardware  procurement  specifications 
the  use  of  a  standard  signal  interface  specification  should  be  considered. 
Operational  modes  also  must  be  established  before  the  design  of  the  test 
system  hardware  can  be  specified. 


3.2. 1.1  Standard  Signal  Interface  Specification 

Since  the  test  system  hardware  procurement  usually  occurs  at  the  same 
time  as  the  procurement  of  the  systems  under  test,  signal  interface  require¬ 
ments  must  be  clearly  established  before  any  procurement  specifications  are 
released.  One  means  of  assuring  compatible  signal  interfaces  is  the  preparation 
of  a  separate  standard  signal  interface  requirements  specifications.  The 
requirements  of  this  specification  can  then  be  imposed  on  the  hardware  sub¬ 
contractors  of  the  test  system  as  well  as  on  the  suppliers  of  systems  under 
test.  As  an  example  of  a  standard  signal  interface  specification,  refer  to 
Appendix  C. 
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In  order  for  the  contractor  to  develop  this  kind  of  specification,  inputs 
by  all  internal  engineering  disciplines  having  procurement  responsibility  must 
be  made.  These  inputs  must  be  then  organized  into  a  preliminary  specification 
for  review  and  finalization. 

3. 2. 1.2  Operational  Modes 

In  order  to  properly  implement  the  test  functions,  several  modes  of  test 
system  operation  may  be  necessary.  Changing  modes  may  affect  actual  testing 
or  may  only  affect  the  display  function.  Mode  selection  would  normally  be  a 
cockpit  switch  function,  although  the  selection  of  certain  modes  may  also 
require  interlocks  involving  certain  key  aircraft  parameters.  The  following 
are  typical  test  system  inodes: 

1.  Dynamic  test  mode  -  This  mode  may  be  manually  selected  or  auto¬ 
matically  entered  in  the  absence  of  any  other  mode  selected. 

In  this  mode  the  systems  under  test  would  be  monitored  on  a 
non-interference  basis  during  usual  systems  operation.  Depend¬ 
ing  on  the  display  mechanization,  two  submodes,  fault  detection 
and  fault  isolation,  may  be  required  to  display  detected  faults 
or  failed  LRU  isolation  messages. 

2.  Ground  active  test  mode  -  This  mode  must  be  manually  selected 
and  interlocked  with  key  aircraft  parameters  such  as  weight - 
on-wheels ,  engine  speed,  or  aircraft  velocity  such  that  inad¬ 
vertent  mode  entry  is  precluded.  In  this  mode  a  selected 
system  or  group  of  systems  can  be  actively  tested  by  the  inter¬ 
ruption  of  normal  operation  and  the  automatic  application  of 
stimuli  to  cause  certain  predictable  responses.  Where  poten¬ 
tially  hazardous  operation  exists  such  as  the  automatic  movement 
of  control  surfaces  or  doors,  a  man -in -the -loop  interlock  must 

be  mechanized  as  a  part  of  the  active  mode  selection.  In  addition 
to  software  interlocks,  sufficient  hardware  interlocks  must  be 
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implemented  to  prevent  inadvertent  application  of  test  system 
stimuli  to  all  systems  under  test. 

As  with  the  dynamic  test  mode,  fault  detection  and  fault  iso¬ 
lation  submodes  may  be  necessary  depending  on  the  display 
mechanization. 

3.  Self -test  mode  -  This  mode  can  be  manually  selected,  auto¬ 
matically  entered  at  power-up,  or  automatically  entered 
periodically.  The  purpose  of  this  mode  is  to  verify  the 
integrity  of  the  test  system  such  that  a  test  system  failure 
will  not  be  interpreted  as  a  failure  of  a  system  under  test. 

4.  Parameter  monitor  mode  -  This  mode,  which  must  be  manually 
selected,  is  used  to  display  the  status  of  any  test  signal 
acquired  by  the  test  system.  This  mode  should  be  a  parallel 
mode  to  the  dynamic  and  ground  active  test  modes  such  that 
the  testing  function  will  not  be  interrupted  if  parameter 
monitor  is  selected. 

During  the  development  of  the  test  system  display  function, 
one  important  factor  to  consider  is  the  capability  of  dis¬ 
playing  more  than  one  signal  at  a  time.  With  many  systems 
being  dual-,  triple-,  or  quad- redundant  and  with  the  probable 
absence  of  ground  equipment,  it  may  be  necessary  to  display 
all  redundant  channels  of  a  given  signal  simultaneously. 

5.  Data  entry  mode  -  This  mode  may  be  necessary  if  a  hardcopy 
printer  or  recorder  is  implemented  in  the  test  system  design. 
This  mode  would  be  used  for  identifying  printer  or  recorder 
data  with  key  information  such  as  the  date,  aircraft  iden¬ 
tification  number,  and  engine  number(s). 

This  mode,  which  must  be  manually  selected,  requires  a  key¬ 
board  for  data  entry.  This  mode  should  also  be  a  parallel 
mode  to  the  test  modes  such  that  selection  of  this  mode  will 
not  interrupt  testing. 
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3.2.2  SYSTEM  UNDER  TEST 

For  the  purpose  of  this  section,  the  system  under  test  will  be  defined 
as  that  LRU  or  group  of  LRU's  which  are  procured  with  a  single  specification. 
It  must  be  noted  that  functional  requirements  will  vary  between  single  and 
multiple  LRU  systems.  For  example,  an  LRU  fault  isolation  requirement  cannot 
be  imposed  on  the  supplier  of  a  single  LRU  system  if  an  interfacing  LRU  fail¬ 
ure  can  result  in  a  malfunction  of  the  single  LRU  system,  since  the  supplier 
should  not  be  held  responsible  for  failures  of  systems  other  than  his  own. 

The  determination  and  resolution  of  such  ambiguities  must  be  made  by  the 
contractor. 

3. 2. 2.1  Test  Objective 

In  the  specification  of  functional  requirements  for  a  system’s  test  pro¬ 
visions,  the  extent  or  goal  of  testing  must  be  established.  As  with  reli¬ 
ability  and  maintainability,  the  capability  of  a  system  to  be  tested  must  be 
quantitatively  specified.  Since  the  purpose  of  the  test  system  is  to  detect 
and  isolate  faults  with  a  minimum  number  of  false  indications,  the  following 
areas  must  be  included  when  establishing  the  extent  of  the  test  provisions 
for  the  system  under  test. 

1.  Fault  detection  -  The  ability  to  detect  faults  based  on  the 
real-time  computer  analysis  of  the  system's  test  signals 
must  be  defined.  The  fault  detection  criteria  may  be  defined 
as  the  percentage  of  the  system's  failure  rate  which  can  be 
detected  by  the  computer  processing  and  analysis  of  the  test 
signal  provisions  of  the  system  under  test. 

2.  Fault  isolation  -  Next  to  the  detection  of  faults,  one  of  the 
main  objectives  of  a  test  system  is  the  reduction  of  maintenance 
manhours.  In  order  for  a  test  system  to  significantly  reduce 
maintenance  time,  the  system  under  test  must  provide  sufficient 
test  points  to  allow  effective  isolation  of  faults  to  the  LRU 
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level.  As  with  the  specific  fault  detection  requirement, 
fault  isolation  may  be  defined  as  a  percentage  of  a  system's 
detectable  failure  rate  which  can  be  isolated  to  the  LRU 
level. 

3. 2. 2. 2  Interface  With  Test  System 

After  the  test  system  interface  requirements  have  been  established  for 
the  procurement  of  the  test  system  hardware,  compatible  interface  require¬ 
ments  must  be  imposed  on  the  design  of  the  system  under  test.  During  the 
design  phase  of  the  system  under  test,  a  trade  study  should  be  conducted 
to  determine  if  multiplexing  techniques  would  be  more  effective  than  indi¬ 
vidual  wire  interfaces.  This  trade  study  should  take  into  consideration 
the  following  factors:  wire  size,  length,  and  weight;  multiplexer  cost, 
weight,  reliability,  accuracy,  signal  capacity,  and  access  time. 

3. 2. 2. 2.1  Signals 

Since  it  is  impractical  to  design  test  system  hardware  to  interface 
with  any  type  of  test  signal,  several  standard  interface  types  must  be 
established.  Once  these  standard  interfaces  have  been  established,  the 
system  under  test  must  provide  the  necessary  signal  conditioning  to  insure 
a  compatible  interface  with  the  test  signal. 

The  following  information  describes  basic  test  signal  interface  charac¬ 
teristics  which  must  be  specified  in  the  procurement  of  the  system  under 
test: 

1.  Analog  -  Voltage  range,  frequency  limits,  accuracy,  linearity. 

2.  Discrete  inputs  and  outputs  -  Logic  voltage  levels,  rise  and 
fall  times. 

3.  Serial  digital  inputs  and  outputs  -  Bit  count,  parity,  logic 
voltage  levels,  rise  and  fall  times,  synchronization  pulse, 
clocking,  data  rate,  address  word  format,  data  word  format, 
message  word  count,  maximum  waveform  distortion. 
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3. 2. 2. 2. 2  Isolation 

The  test  signals  provided  by  the  system  under  test  must  be  conditioned 
and  buffered  such  that  a  failure  of  test  system  hardware  or  interface  wiring 
will  not  cause  degradation  of  the  operation  of  the  system  under  test. 

Efforts  must  be  made  in  the  design  of  the  test  signal  interface  circuit¬ 
ry  such  that  failures  of  this  circuitry  or  interface  wiring  will  be  detected 
by  the  test  system.  In  addition  to  detecting  failures  of  these  test  provisions, 
consideration  must  be  given  to  the  capability  of  differentiating  test  pro¬ 
vision  failures  from  actual  failures  of  the  system  under  test. 

3. 2. 2. 2. 3  Impedance 

In  addition  to  the  signal  characteristics  listed  above,  the  input  and 
output  impedance  requirements  must  be  specified.  The  type  and  maximum  length 
of  system-under-test  to  test-system  interconnect  cabling  must  also  be  specified, 
including  cable  impedance ,  distributed  capacitance,  and  shielding. 

3. 2. 2. 2. 4  Output  Circuit  Drive  Capability 

In  order  to  provide  the  test  system  with  intelligible  signals,  the  mini¬ 
mum  drive  current  of  the  test  signal  output  circuitry  of  the  system  under  test 
must  be  specified.  The  specific  output  current  requirement  should  be  based 
on  cable  length,  cable  type,  and  input  impedance  of  the  test  system  circuits. 

3. 2. 2. 3  Development  Testing 

The  majority  of  the  onboard  test  system  test  performance  evaluation  is 
accomplished  by  means  of  analysis  of  supplier  submitted  data  and  is  received 
by  the  prime  contractor.  However,  certain  development  testing  is  required  to 
demonstrate  the  performance  and  effectiveness  of  the  onboard  test  system 
detection  and  isolation  capabilities. 

After  receipt  of  the  supplier  analysis  data,  and  after  a  review  by  the 
prime  contractor  has  resulted  in  a  preliminary  or  conditional  approval  of 
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the  analysis,  a  development  test  should  be  conducted  at  the  supplier's 
facility.  This  test  should  utilize  a  breadboard  or  prototype  version  of 
the  design  as  described  by  the  analysis,  and  should  be  accomplished  as  soon 
as  possible  after  this  non -product ion  unit  is  available.  This  testing  is 
not  to  be  construed  as  a  part  of  either  prequalification  testing  or  acceptance 
testing  and  should  be  completed  well  ahead  of  the  beginning  of  prequalification 
testing. 

The  test  should  verify  the  performance  of  the  onboard  test  system  by 
actually  simulating  a  number  of  failure  conditions.  These  failure  conditions 
would  be  monitored  to  verify  that  the  onboard  test  system  detects/isolates 
the  indicated  fault  as  documented  in  the  supplier's  data.  These  simulated 
faults  would  be  selected  by  the  prime  contractor  and  the  quantity  of  tests 
should  be  based  on  a  percentage  of  the  total  possible  number  of  failure 
indications  of  the  subsystem.  This  selection  should  include  all  failure 
conditions  affecting  safety-of-flight  and  mission  critical  modes.  During 
the  simulation  of  each  failure  condition,  each  of  the  applicable  test  signals 
characteristics  should  be  monitored  to  validate  its  compliance  with  the 
defined  failure.  In  the  event  that  any  of  the  required  demonstrations  fail, 
then  the  prime  contractor  would  select  additional  tests  to  provide  the  required 
confidence  level  in  the  onboard  test  system  demonstration.  Also  the  supplier 
would  be  responsible  for  re-evaluating  the  faulted  condition  and  providing  an 
adequate  fix  or  an  acceptable  alternative. 

3. 2. 2. 3.1  Failure  Criteria 

A  firm  definition  of  the  system  failure  criteria  is  required  as  a  base 
for  established  testing  requirements.  This  criteria  should  utilize  the  system 
performance  requirements  as  a  foundation  in  determining  these  failure  defi¬ 
nitions.  However,  when  utilizing  these  performance  requirements,  insure  that 
realistic  test  limits  are  provided  for  testing  the  system  in  its  operational 
environment.  Establishment  of  the  failure  criteria  should  include: 
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1.  Sufficient  test  delays  to  cover  normal  system  response  times. 

2.  Adequate  test  tolerances  for  system/test  system  transducer 
measurements . 

3.  Allowance  for  transient  system  operating  conditions  (system 
warm-up/mode  changes)  before  indicating  a  failure. 

Once  the  failure  criteria  have  been  defined,  then  adequate  testing/ 
monitoring  of  system  operation  should  be  specified  to  validate  the  test 
system  capability  to  detect  and  isolate  these  failure  conditions. 

3. 2. 2. 3. 2  Test  Signals 

Specific  testing  of  each  test  signal's  performance  is  essential  to  a 
successful  test  mechanization.  During  the  development  phase  of  the  test 
system,  each  test  signal  should  be  analyzed  to  determine  the  specific  tests 
required  for  its  validation.  These  tests  should  exercise  the  test  signal 
over  its  full  range  of  required  operation,  thus  insuring  that  signal  accuracy 
meets  the  specified  requirements.  The  signal  accuracy  and  repeatability  test¬ 
ing  should  be  specified  to  cover  all  the  required  test  areas  (e.g.,  approaching 
the  test  limits  from  all  directions,  increasing/ decreasing  measurements,  and 
checking  hysteresis) .  Each  signal  should  be  monitored  during  dynamic  conditions 
of  system  operation  to  verify  the  noise  rejection  capability  of  the  test  cir¬ 
cuitry. 

3. 2. 2. 4  Data  Requirements 

To  arrive  at  an  optimum  test  system  design,  the  designer  requires  much 
detailed  data  covering  system  requirements,  design,  reliability,  failure  data, 
interface  signal  definition,  and  much  more.  Defined  in  the  subsequent  para¬ 
graphs  are  the  various  data  requirements  necessary  to  accomplish  the  test 
system  design.  In  addition,  format /extent  of  the  required  data  has  been 
specified  to  insure  completeness  and  facilitate  expeditious  review/usage  of 
the  data.  Timely  compliance  with  complete  fulfillment  of  the  data  requirements 


is  also  a  key  factor  in  the  successful  design  of  the  test  system.  To  insure 
achievement  of  this  requirement,  a  strong  initial  effort  with  the  subcontractor 
is  required.  This  effort  includes  initial  coordination/briefings  on  the  test 
system  concept/capability/mechanization,  plus  a  review  of  the  data  requirements 
so  necessary  for  the  design  evaluation. 

Proper  scheduling  of  the  data  submittals  are  essential  in  order  to  accom¬ 
plish  the  necessary  review  in  a  timely  manner  for  incorporat ion  of  any  required 
changes  without  impacting  hardware  design/fabrication  schedules.  The  initial 
data  submittal  should  occur  at  least  2  weeks  prior  to  the  Preliminary  Design 
Review  (PDR)  of  the  system.  The  second  submittal  should  occur  no  later  than 
2  weeks  prior  to  Critical  Design  Review  (CDR) .  The  final  submittal  should 
occur  at  least  1  month  prior  to  hardware  delivery.  Interim  submittals  may  be 
required  to  incorporate  revisions  made  necessary  by  system  design  review  changes. 
Timely  resubmittal  dates  should  be  negotiated  and  established  as  soon  as  the 
need  for  changes  becomes  apparent.  Based  on  past  experience,  the  majority  of 
any  required  changes  must  be  incorporated  by  PDR,  because  when  CDR  arrives, 
hardware  is  being  fabricated  and  changes  are  difficult  and  costly  to  incorporate. 
Consequently,  adherence  to  the  above  mentioned  data  requirements/schedules  are 
mandatory. 


3. 2. 2. 4.1  Failure  Modes  and  Effects  Analysis  (FMEA) 

The  FMEA  is  a  most  important  document  since  it  defines  the  failure  data 
associated  with  the  system  under  test.  In  order  to  perform  an  FMEA  on  a  system 
the  first  requirement  is  to  establish  the  basic  performance,  safety,  maintenance, 
and  inspection  criteria  for  overall  evaluation  and  to  identify  the  elements  and 
functions  of  the  system.  FMEA's  are  derived  from  functional  flow  diagrams, 
scf  ematics,  and  timing  sequence  diagrams  and  are  then  used  to  identify  components 
affecting  the  different  failure  modes,  /in  example  of  an  FMEA,  with  typical 
entries,  is  shown  in  Figure  3-4.  A  description  of  the  format  used  is  given  in 
Tab.ie  III -2. 
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FMEA  FORMAT  DESCRIPTION 

1.  Nomenclature  -  Name  of  component /equipment  in  the  subsystem  being  analyzed. 
Nomenlature  to  be  consistent  throughout  all  documentation,  using  only 
approved  abbreviations  as  applicable. 

2.  Identification  Number  -  Drawing  number  or  part  number  by  which  component 
or  module  is  identified. 

3.  Drawing  Reference  Designation  -  Indicate  reference  designation  used  to 
identify  component  or  module  on  schematic.  The  designation  number  will 

be  assigned  by  the  contractor  in  accordance  with  DOD-STD-863  specification. 
Applicable  schematic  and  wiring  diagram  numbers  should  be  listed. 

4.  Component/System  Purpose,  Function,  and  When  Used  -  Concise  statement  of 
the  function  performed.  The  specific  mission  phase  during  which  the  item 
is  required  to  operate  should  be  listed. 

The  mission  phase  classifications  are:  (1)  ground  alert,  (2)  engine  start, 
(3)  taxi,  (4)  takeoff,  (5)  climb,  (6)  refueling,  (7)  subsonic  cruise-high 
altitude,  (8)  subsonic  dash-low  altitude,  (9)  weapon  delivery,  (10)  super¬ 
sonic  cruise,  (11)  descent,  (12)  approach,  (13)  landing,  and  (14)  ground 
operations. 

These  phases  may  be  further  subdivided  or  combined,  as  appropriate,  (i.e., 
all  flight  phases,  prior  to  weapon  delivery). 

5.  Failure  Mode  Identification  Number  -  Each  failure  mode  listed  is  to  be 
identified  by  a  unique  number.  Each  number  is  to  be  prefixed  by  a  sub¬ 
system  code  identification  number  assigned  by  the  subcontractor  in  accord¬ 
ance  with  DOD-STD-863  specification. 

6.  Fail  Mode  Description  -  Only  the  category  of  the  failure  is  to  be  given. 

For  example,  note  only  that  a  valve  has  failed  "open".  Do  not  enumerate 
the  ways  of  failing  open.  All  possible  failure  modes  for  each  item  are 
to  be  listed  whether  their  signifiance  is  great  or  small. 
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7.  Failure  Rate  -  Give  the  failure  rate  for  the  failure  mode  in  terms  of 
failures  per  million  operating  hours.  The  failure  rate  figure  shall 
consider  environment,  stress,  and  other  applicable  conditions  relative 
to  component  usage  in  these  computations.  Reliability  predictions  for 
military  electronic  equipment  should  use  MIL-HDBK-217  as  a  guide  for  these 
computations . 

8.  Component/Functional  Assembly  -  Describe  the  immediate  effect  of  the  assumed 
failure  mode  on  function/subsystem  operation,  indicating  the  resulting 
function  failure  state,  if  any.  A  function  failure  state  is  generally 
defined  as  a  degradation  or  loss  of  one  or  more  discrete  outputs  of  a 
function. 

9.  Aircraft  System  -  A  brief  description  of  the  effect  of  the  failure  on  the 
aircraft  system. 

10.  Total  Aircraft  -  A  description  of  the  effect  of  the  component  failure  on 
the  total  aircraft  performance.  The  narrative  should  support  the  crit¬ 
icality  levels  specified. 

11.  Criticality  Level  -  Classify  each  assumed  function  failure  state  according 
to  its  level  of  safety  of  flight,  safety  of  personnel,  safety  of  equipment, 
and  mission  success.  See  paragraph  3. 2. 2. 4. 1.3  for  criticality  category 
levels.  For  safety  of  flight  use  "S"  for  safe  flight  and  "IF'  for  unsafe 
flight. 

12.  When  Discovered,  How  Detected  -  Indicate  when  and  how  the  assumed  failure 
mode  would  be  detected.  For  example,  a  failure  may  be  detected  by  actuation 
of  a  warning  device,  by  an  erratic  or  improper  indicator  reading,  by  a 
noticeable  degradation  in  aircraft  performance,  or  by  a  ground  test  or 
inspection.  If  the  failure  mode  would  be  detected  by  the  onboard  test 
system,  so  indicate. 

13.  Test  System  Detection  Method  ••  Cross-reference  the  identification  number  of 
the  test  logic  diagram  block  that  detects  this  failure  mode.  This  number 
is  arbitrarily  assigned  by  the  subcontractor  during  test  logic  development. 
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14.  Test  System  Isolation  Method  -  Cross-reference  the  identification  number 
of  the  test  logic  diagram  block  that  isolates  this  failure  mode.  This 
number  is  arbitrarily  assigned  by  the  subcontractor  during  test  logic 
development. 

IB.  Corrective  Action  and  Safety  Factor  Available  -  Describe  any  compensating 
provisions,  either  automatic  or  required  by  an  operator,  which  allow 
continued  system  operation  or  control.  List  all  fail-safe  features. 

16.  Comments/Recommendations  -  Include  additional  information  needed  to 

clarify  the  data  in  the  other  columns.  Also  include  any  recommendations 
for  design  or  procedural  changes,  or  additional  testing  to  reduce  crit¬ 
icality  of  the  assumed  failure  mode.  Comment  on  any  problem  areas  that 
may  require  special  consideration. 
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3. 2. 2.4. 1.1  Failure  Criteria.  Definition  of  system  failure  criteria  should 
be  provided  along  with  the  tolerance  for  the  GO/NO-OO  determination.  Degraded 
modes  of  system  operation  should  also  be  identified  for  evaluation  of  detect - 
t ion/isolation  requirements  and  the  duration  they  can  exist,  before  the  test 
system  should  indicate  them  as  a  failure. 

3. 2. 2. 4. 1.2  Failure  Rates.  The  failure  rates  for  the  system/LRU's /test  circu¬ 
itry  shall  be  defined  in  the  FMEA.  The  failure  rate  unit  shall  be  defined  as 
the  number  of  failures  per  million  hours  of  operation.  The  failure  rates  of 
the  test  components/test  circuitry  shall  be  listed  in  the  system  FMEA. 

3. 2. 2. 4. 1.3  Criticality  of  Failure  Modes.  The  criticality  of  each  failure 
mode  should  be  identified  in  the  FMEA.  This  criticality  classification  is  to 
be  assigned  to  each  failure  mode  according  to  its  effect  on  the  operational 
mission  or  in  causing  personnel,  equipment,  or  property  to  be  exposed  to 
hazardous  conditions.  The  functional  effect  of  loss  or  degradation  should  be 
identified  so  that  the  failure  mode  effect  can  be  properly  categorized.  The 
criticality  categories  are  defined  as  follows  for  the  purpose  of  tliis  document: 

Safety-of - Flight : 

A.  Safe  Flight  -  The  absence  of  failures  during  takeoff,  flight, 
or  landing  which  prevent  a  qualified  crew  from:  (1)  sustaining 
flight  (with  possible  reduced  range  and/or  performance,  (2) 
safely  landing  the  aircraft,  or  (3)  safely  aborting  takeoff. 

This  definition  encompasses  not  only  those  failures  which 
result  in  an  immediate  unsafe  condition,  but  also  those 
failures  which  permit  contained  safe  flight  but  preclude 

a  safe  controlled  landing. 

B.  Unsafe  Flight  Conditior  -  The  occurrence  of  material  failures 
which  preclude  safe  flight  as  defined  above. 
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Safety  of  Personnel  -  Hazard  levels: 

Category  I  -  Catastrophic  -  May  cause  death. 

Category  II  -  Critical  -  May  cause  severe  injury  or  severe 

occupational  illness. 

Category  III  -  Marginal  -  May  cause  minor  injury  or  minor 

occupational  illness. 

Category  IV  -  Negligible  -  Will  not  result  in  injury. 

Safety  of  Equipment  -  Hazard  levels: 

Category  I  -  Catastrophic  -  May  cause  system  loss. 

Category  II  -  Critical  -  May  cause  major  system  damage. 

Category  III  -  Marginal  -  May  cause  minor  system  damage. 

Category  IV  -  Negligible  -  Will  not  result  in  system  daji  lge. 

Mission  Success  Levels: 

Level  A  -  No  effect  on  mission  success. 

Level  B  -  Mission  can  be  successfully  completed,  but  with 
significantly  degraded  performance. 

Level  C  -  Mission  cannot  be  successfully  completed. 

The  foregoing  classification/ definitions  should  be  compared  against  any 
imposed  reliability,  safety  or  mission  reliability  specifications  to  insure 
that  conflicts  do  not  exist. 

3. 2. 2. 4. 2  Block  Diagrams 

P.lock  diagrams  of  the  system  shall  be  provided  which  identify  the  func¬ 
tional  elements  and  signal  flow.  These  diagrams  require  identification  of  the 
interface  signals  between  the  system  and  other  subsystems,  signal  flow  between 
system  LRU's,  and  the  location  of  the  test  parameters  to  be  used  for  system 
monitoring.  The  method  of  identification  of  LRU's  and  test  signals/parameters 
shall  be  consistent  with  the  method  used  in  the  LRU  list,  the  test  parameter 
list,  FMEA,  and  the  test  logic  to  provide  accurate  and  easy  correlation  and 
cross-reference.  An  example  of  this  type  of  block  diagram  is  shown  in  Figure 
3-5. 
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3. 2. 2. 4. 2.1  LRU's.  Once  the  block  diagrams  are  available,  a  list  of  the  LRU's 
making  up  the  system  should  be  prepared.  A  firm  definition  of  what  constitutes 
an  LRU  must  be  clearly  established  and  followed  in  preparing  the  list,  since 
this  is  the  basis  of  meeting  the  LRU  isolation  certainty  requirements.  From 
this  each  LRU  can  be  evaluated  to  verify  that  all  specified  failure  modes  in 
the  FMEA  are  being  detected  and  that  unique  isolation  of  these  failures  to  that 
LRU  are  being  accomplished.  An  LRU  list  example  is  given  in  Figure  3-6.  Table 
III- 3  describes  the  LRU  list  format  and  content. 

3. 2. 2. 4. 2. 2  Input/Output  Signals.  The  signal  flow  indicated  on  the  block 
diagram  is  used  to  define  the  operational  input/output  signals.  This  list 
should  include  a  definition  of  the  operational  signals  recommended  to  be 
monitored  during  the  test  sequence  and  should  include:  a)  electrical  inter¬ 
face  definition  in  terms  of  voltage  level  and  impedance;  b)  range  of  variation 
and  nominal  and  worst-case  operational  use;  and  c)  signal  response  character¬ 
istics. 


3. 2. 2. 4. 2. 3  Power.  The  power  requirements  defined  by  the  system  under  test 
must  meet  the  requirements  of  the  generating  source.  In  addition,  system 
operation  during  degraded  power  modes  (loss  of  one  phase  or  under  voltage) 
should  be  analyzed  for  the  effect  on  test  parameters.  Development  of  the 
test  logic  should  contain  adequate  precondition  test  parameters  to  verify 
that  basic  power  requirements  are  met  before  testing  is  performed. 

Power  utilization  within  the  system's  LRU's  must  also  be  reviewed  to 
insure  that  noise  from  these  lines  does  no.  adverseley  affect  the  test  para¬ 
meters. 


3. 2. 2. 4. 3  Test  Parameter  List 

A  complete  listing  of  the  recommended  test  parameters  and  their  char¬ 
acteristics  must  be  pro\ided  to  accomplish  the  required  analysis  (see  Figure 
3-7).  Test  parameter  list  definitions  are  given  in  Table  III -4. 
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LRU  TOTAL  LRU  FAILURE  RATE  FAILURE  RATI  FAILURE  RAT 

IDENTIFICATION  SELECTED  FAILURE  RATI  DETECTED  ISOLATED  BY  NOT  DET/ 

iUANTITY  NUMBER  DESCRIPTION  FOR  ISOL  PER  106  HRS  BY  TEST  SYS  TEST  SYS  ISOLATED 


© 


Figure  3-6 


Table  III-3 


LRU  LIST 


Quantity  -  Enter  the  quantity  of  the  particular  LRU  comprising  a  part 
of  the  subsystem. 

Identification  Number  -  Enter  identification  number  of  LRU  (part  number/ 
reference  designator/etc.  that  is  consistent  with  all  other  documentation). 
Description  -  Enter  description/nomenclature  of  LRU  that  is  descriptive  of 
subsystem/LRU/ function/location/ etc. ,  and  is  consistent  throughout  all 
other  documentation. 

LRU  Selected  for  Isolation  -  Enter  "Yes"  or  "No"  depending  on  whether  or 
not  LRU  is  selected  for  failure  isolation  by  test  system. 

Failure  Rate  Data  of  LRU  (Failures  per  million  hours  of  operation)  -  Enter 
applicable  accumulated  failure  rate  data  from  subsystem's  FMEA  for  each 
LRU  failure  category  as  noted  in  each  column. 


SUBSYSTEM  X-l  AIRCRAFT 


Test  Parameter  List 
Figure  3-7 
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Table  III -4 


TEST  PARAMETER  LIST  DEFINITIONS 

©  Parameter  Identification  Number  -  Each  test  parameter  shall  be  assigned  an 
identification  number.  This  number  will  correlate  the  parameter  to  its 
usage  in  the  test  logic  diagrams,  schematics,  and  block  diagrams.  This 
number  is  arbitrarily  assigned  by  the  subcontractor. 

©  Description  -  Provide  an  adequate  description  of  the  test  parameter  as 
defined  in  paragraph  3. 2. 2. 4. 3.1. 

©)  Source  -  Identify  the  LRU  where  the  signal  originates. 

(J)  Signal  Type  -  Identify  the  type  signal  being  provided  (e.g. ,  discrete, 
packed  discrete,  analog,  multiplexed  analog,  serial  digital,  etc.) 

(5)  Operational  Range  -  Define  the  operational  range  of  the  signal  in  terms 
of  engineering  units  (e.g.,  0-30  PSIA,  70°  -  120°F) . 

For  discrete  signals,  define  trip  point,  tolerance,  and  direction  of 
measurement  (e.g.,  "1"  logic  at  170°F  +  3°F  on  increasing  temperature) . 

©  Response  Time  -  Define  response  time  of  signal  to  change  state  for  full 
scale  reading  (e.g.,  from  minimum  temperature  range  to  maximum  range; 
from  full  closed  (logic  "0")  to  full  open  (logic  "1") ;  from  zero  pressure 
(logic  "0")  to  140  PSIA  (logic  "1")). 

©  Normal  Range  -  Define  normal  operating  range  of  signal  in  engineering 
units. 

©  Tolerance  -  Define  tolerance  of  signal  over  full  range  of  operation  in 
engineering  units. 

©  Conversion  Factor  -  Define  conversion  factor  of  signals  from  engineering 
units  to  volts;  may  be  expressed  as  formula,  tabulated  table,  or  in  graph 
form. 
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3. 2. 2. 4. 3.1  Nomenclature.  The  nomenclature  assigned  to  the  test  parameters 
should  be  descriptive  of  the  operation  signal  being  monitored.  This  nomen¬ 
clature  should  also  include  location  (left  hand  (IH) ,  right  hand  (RH) ,  forward, 
aft)  and  system  application  (system  1  or  2,  primary,  or  secondary)  as  applicable 
and  use  only  approved  abbreviations  and  acronyms.  If  possible,  discrete  type 
signals  should  also  contain  nomenclature  defining  function  for  the  logic  "1" 
signal  state  (e.g.,  on/off,  open/closed,  energized/de -energized) . 

3. 2. 2. 4. 3. 2  Type.  The  type  signals  being  provided  as  test  parameters  must 
be  adequately  defined  and  be  in  accordance  with  the  specified  type  signals 
that  the  test  system  will  accept.  The  data  should  specify  the  type  transducers 
being  recommended  and  include:  a)  electrical  interface  definition  in  terms  of 
voltage  output,  input,  and  impedance ;  b)  response  characteristics;  and  c)  tol¬ 
erance  definition  under  nominal  and  worst -case  conditions  of  use  and  environ¬ 
ment. 

3. 2. 2. 4. 3. 3  Characteristics .  Define  the  test  characteristics  for  each  para¬ 
meter  being  recommended  for  testing.  These  characteristics  shall  be  defined 
in  engineering  units  for  the  categories  listed  below: 

Normal  -  Define  the  normal  characteristics  of  each  test  parameter 
for  all  modes  of  system  operation. 

Failure  -  Define  the  failure  characteristics  for  each  test  parameter 
during  all  modes  of  operation. 

3. 2. 2. 4. 3. 4  Conversion  Factors.  Conversion  factors  for  each  test  parameter 
shall  be  provided.  The  factors  shall  define  the  test  measurement  correlation 
to  engineering  units  or  function  and  also  provide  the  test  tolerance  for  the 
parameter  over  the  full  scale  of  operation  as  applicable. 
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3. 2. 2. 4. 4  Preliminary  Test  Logic 

Preliminary  test  logic  diagrams  shall  be  provided  for  each  system  under 
test.  The  diagrams  shall  provide  the  test  logic  necessary  to  meet  the  spec¬ 
ified  failure  detection  and  isolation  requirements  for  all  modes  of  system 
operation.  These  diagrams  shall  also  specify  the  necessary  test  pre-conditions 
and  system  warm-up  times  required  before  entering  the  test  routine.  The  test 
logic  diagrams  shall  utilize  the  symbols  in  Figure  3-8.  The  output  failure 
block  should  contain  an  identification  number  which  correlates  to  the  appli¬ 
cable  failure  mode  in  the  FMEA.  An  example  of  test  logic  is  shown  in  Figure 
3-9. 


3. 2. 2.4.5  Preliminary  Calculations 

Preliminary  calculations  demonstrating  compliance  with  the  detection  and 
isolation  requirements  shall  be  provided  in  accordance  with  the  applicable 
equations.  These  calculations  shall  utilize  the  most  current  FMEA  system  data. 

3. 2. 2. 4. 5.1  Detection  Assurance.  Detection  assurance  computation  in  accord¬ 
ance  with  the  defined  method  shall  be  provided.  These  calculations  shall  i  :i- 
lize  the  failure  mode  and  failure  rate  data  of  the  applicable  system  FMEA. 

The  failure  modes  detected  by  the  test  system  shall  be  identified  as  well  as 
those  which  will  not  be  detected.  All  failure  modes  established  as  affecting 
in-flight  safety  must  be  detected  and  indicated.  The  computations  shall  cover 
each  mode  of  system  operation.  Conditr  -ulting  in  degraded  system/  LRU 
operation  shall  be  detected  and  indicated  a-  advisory  message  (not  as  a 
failure)  for  possible  maintenance  action. 

3. 2. 2.4. 5. 2  Isolation  Certainty.  Isolation  certainty  computations  should  be 
provided  in  accordance  with  the  defined  method.  Computations  for  each  LRU 
should  be  provided  in  enough  detail  to:  1)  identify  the  failure  rate  for  each 
LRU  failure  mode  that  is  isolated  as  well  as  for  those  not  isolated,  2)  specify 
those  LRU's  that  are  uniquely  isolated,  and  3)  specify  those  LRU's  that  are 
isolated  in  groups  of  two  or  more. 
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Enter,  exit, 
time  delay 


Operat ion/Process 


Decision 


AA:  Parameter  Identification  Number 
(from  Test  Parameter  List) 


Input/Output 


On-page  connector 


XX:  Failure  ID  Number  (arbitrarily 

assigned  by  contractor/subcontractor, 
for  cross  reference  to  FMEA) 

YY:  Failure  Message  (identifies 
failed  system) 

ZZ:  LRU  Work  Unit  Code  (WUC)  Number/s 
(in  order  of  highest  failure  rate 
if  multiple  LRU's) 


Off -page  connector 


Flow  direction  -  -  1  — 


Confluence 


t 
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Test  Logic  Diagram  Symbols 
Figure  3-8 
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NOTE:  THIS  DIAGRAM  IS  FOR  ILLUSTRATION 
ONLY  AND  IS  NOT  INTENDED  AS  REAL 
DATA. 


MSG:  ECS  CREW  PK  OFF 
WUC:  41BAA 

(1112-1  CREW  PK  B/P  VALVE 
FAILED  CLOSED) 


Crew  Pack  Test  Logic  (Exanple) 
Figure  3-9 


Special  attention  should  be  given  to  those  calculations  involving  partial 
credit  for  ambiguous  isolation,  so  that  sufficient  information  is  available  to 
allow  the  evaluation  of  alternate  isolation  testing  schemes. 

3.3  EVALUATION  OF  SUPPLIER  DATA 

The  foundation  for  development  of  an  effective  test  system  is  the  timely 
acquisition  of  proper  and  adequate  data  for  evaluation.  Therefore,  to  insure 
the  availability  of  the  data  in  conformance  with  a  submittal  schedule,  it  is 
advisable  to  coordinate  with  the  supplier  periodically  prior  to  the  due  date 
to  verify  data  completeness  and  progress  status. 

If  problem  areas  exist,  special  effort  should  be  expended  to  correct  any 
discrepancies  or  anomalies  without  disrupting  the  schedule  or  extending  the 
completion  date.  Once  the  data  is  received,  copies  should  be  distributed  to 
the  other  affected/supporting  design  groups  for  their  concurrent  review/eval¬ 
uation  and  comments.  A  detailed  methodical  review  of  the  data  as  outlined 
below  should  be  accomplished  to  verify  test  system  requirements  are  met.  In 
addition,  schedule  dates  for  completion  of  the  data  review/comments  should  be 
set  to  insure  timely  resolution  of  problems  and  incorporation  of  changes. 

3.3.1  FAILURE  NODES  AND  EFFECTS  ANALYSIS 

Upon  receipt  of  the  FMEA  it  should  be  reviewed  for  completeness  and 
accuracy.  An  initial  check  should  verify  that  all  columns  are  complete  and 
that  proper  ground  rules  have  been  followed.  If  some  columns  are  inconplete, 
then  the  supplier  should  be  notified  immediately  to  initiate  corrective  action 
so  the  review  is  not  delayed.  In  addition,  a  detailed  check  of  the  data  for 
one  LRU,  selected  at  random,  should  be  conducted  during  this  initial  check  to 
verify  the  acceptability  of  the  FMEA.  The  review  should  include  an  analysis 
of  the  test  circuitry  failure  data  to  evaluate  the  acceptability  of  its  reli¬ 
ability  and  failure  modes  in  relation  to  the  operational  signal  being  monitored. 
Careful  evaluation  of  the  criticality  colunns  is  essential  to  insure  that  all 
safety  critical  failure  inodes  are  being  detected  by  the  test  system. 
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3.3.2  DEVELOPMENT  TEST  RESULTS 

Review  of  the  development  test  results  is  essential  to  insure  proper 
performance  of  the  selected  test  parameters.  This  review  should  include 
analysis  of  the  applicable  test  set-up  for  utilization  of  actual  system 
components.  The  test  results  should  cover  adequate  testing  of  the  parameters 
over  the  full  range  of  operation  and  be  within  the  specified  test  tolerance. 

3.3.3  TEST  SELECTION  ANALYSIS 

Analysis  of  the  FMEA  failure  modes  and  the  test  logic  must  be  conducted 
to  evaluate  the  effectiveness  of  the  recommended  test  routines.  This  eval¬ 
uation  should  verify  that  all  failure  modes  are  detected/isolated  in  the  test 
logic  to  the  extent  specified  by  the  requirements.  The  review  should  also 
validate  the  optimum  usage  of  the  test  parameters  in  performing  the  applicable 
test.  The  effectiveness  of  each  test  should  be  weighed  against  the  criticality 
level  of  the  failure  mode  detected/isolated  and  the  associated  failure  rate 
probability. 

3. 3. 3.1  Order  of  Consideration 

In  reviewing  the  selected  tests,  each  of  the  below  listed  categories 
should  be  given  careful  consideration  in  order  to  validate  their  compliance 
with  the  specified  requirements. 

3. 3. 3. 1.1  Failure  Modes  Impacting  Safety 

During  the  evaluation  of  the  FMEA  and  test  logic,  special  eitphasis  should 
be  applied  to  the  analysis  of  all  failure  modes  affecting  safety  critical 
categories  to  make  certain  that  detection  and  annunciation  of  these  failures 
meet  the  test  system  requirements.  In  this  review,  verify  that  the  criticality 
levels  specified  in  the  FMEA  agree  with  the  proper  classification/level  for 
the  safety  of  flight,  safety  of  personnel,  and  safety  of  equipment  requirements . 
To  aid  in  this  evaluation,  the  narrative  description  of  the  total  aircraft 
failure  mode  in  the  FMEA  should  support  the  criticality  classification/level. 
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3.3. 3.1.2  Failure  Modes  Impacting  Mission  Success 

Validate  the  accuracy  of  the  failure  modes  affecting  mission  success  as 
defined  in  the  FMEA.  This  can  be  accomplished  by  reviewing  the  FMEA  column 
which  defines  the  aircraft  mission  phase  when  the  function  is  required  and 
compare  this  to  the  aircraft  mission  success  requirements.  Once  this  data 
is  validated,  then  the  test  routine  can  be  reviewed  for  proper  detection/ 
annunication  of  these  failure  modes. 

3. 3. 3. 1.3  Failure  Modes  Impacting  System  Performance 

The  final  failure  mode  evaluation  covers  those  items  affecting  system 
performance,  other  than  safety  of  mission  success  related.  These  failure 
modes  would  cover  loss  of  system  function  and/or  degraded  performance.  Each 
of  these  failure  modes  can  be  validated  by  examining  the  output  function  des¬ 
cription  in  terms  of  the  following  typical  possible  failure  modes:  a)  pre¬ 
mature  operation,  b)  failure  to  operate  at  a  prescribed  time,  c)  failure  to 
cease  operation  at  a  prescribed  time,  d)  failure  during  operation,  and  e) 
degradation  or  out-of-tolerance  operation  (depending  on  the  subsystem,  other 
unique  failure  modes  should  be  considered  as  applicable) .  Degraded  modes  of 
operation  should  be  reviewed  to  determine  what  test  system  detect ion/ annunication 
is  required  and  how  maintenance  action  is  initiated. 

3.3.4  PARAMETER  SELECTION  ANALYSIS 

Upon  completing  the  analysis  of  the  FMEA  and  the  recommended  test  routines, 
review  of  the  selected  test  parameters  can  begin.  This  analysis  should  evaluate 
the  effectiveness  of  the  test  parameter(s)  utilized  in  the  detection  routine 
and  the  uniqueness  of  the  LRU  isolation  being  accomplished.  Evaluation  of  these 
test  parameters  can  best  be  analyzed  by  asking  the  following  questions  for  each 
parameter: 


3-51 


A.  Is  the  failure  rate  of  the  test  circuitry  involved  in  the 
conversion  and  scaling  of  the  parameter  realistic  and 
effective  in  relationship  to  the  failure  rate  of  the  system 
circuitry  failure  mode  being  detected/ isolated? 

B.  Is  the  parameter  sensing  point  at  the  optimum  location  in 
the  circuitry  for  monitoring  the  input/cutput  operational 
signal  to  avoid  ambiguous  failure  indications? 

C.  Can  the  validity  of  each  parameter  be  checked  prior  to  usage 
in  the  test  routine? 

Example:  (1)  Are  analog  signals  scaled  such  that  they  can 
be  tested  for  opens/shorts  of  the  test  sensor? 

(2)  Do  discrete  signals  use  logic  "1"  for  GO 
condition,  so  as  to  guard  against  logic  "0" 
failures  of  failed  open  switches,  broken  wires, 
etc.  ? 

D.  Is  the  recommended  parameter,  or  combination  of  parameters, 
optimum/adequate  for  the  required  test? 

Positive  answers  to  the  above  questions  should  provide  an  optimum/cost  effec¬ 
tive  set  of  test  parameters. 

3.3.5  SAFETY  ANALYSIS 

The  safety  aspects  of  each  test  parameter  should  also  be  analyzed.  This 
analysis  should  confirm  the  fail-safe  design  of  the  parameters  in  that  none 
of  the  test  parameter  failure  modes  should  cause  any  system  degradation/ 
failures.  In  addition,  if  test  stimuli  are  used  in  system  testing,  confirm 
that  adequate  hardware  lockouts  are  provided  so  that  a  failed  "on"  condition 
does  not  interrupt  system  operation. 
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3.3.6  PRELIMINARY  CALCULATIONS  ANALYSIS 

Confirmation  of  the  supplier's  detection  assurance/isolation  certainty 
calculations  are  most  important  in  determining  the  effectiveness  of  the  test 
system.  This  will  require  compilation  of  all  the  failure  rates  of  the  system's 
failure  modes  and  then  computation  in  accordance  with  the  defined  detection/ 
isolation  equations  to  validate  that  the  test  requirements  are  met.  As  system 
designs  progress  and  changes  are  incorporated  that  affect  the  FMEA  and  system 
testing,  re-evaluation  of  these  calculations  will  be  required  to  insure  that 
the  test  system  requirements  are  not  impacted. 

3. 3. 6.1  Detection  Assurance 

Validation  of  the  supplier's  detection  assurance  calculation  is  required 
to  insure  compliance  with  the  test  system  detection  requirements.  The  figures 
used  in  the  supplier's  calculation  should  match  the  failure  data  listed  in  the 
system  FMEA  and  test  routine.  Consequently,  compilation  and  computation  of  the 
FMEA  failure  data  for  the  detection/undetected  failure  modes  in  accordance  with 
the  defined  formula  should  conform  to  this  requirement. 

3. 3.6.2  Isolation  Certainty 

Review  of  the  supplier's  isolation  certainty  calculation  should  be  con¬ 
ducted  to  substantiate  compliance  with  the  isolation  requirement.  This  review 
involves  accumulating  the  system's  LRU  failure  rates  (for  detected  failures 
only)  as  defined  in  the  FMEA  and  then  segregating  them  according  to  how  they 
are  isolated  in  the  test  routine.  Care  must  be  taken  that  each  LRU's  failure 
rates  are  properly  separated  so  that  the  correct  calculation  is  used  for  the 
uniquely  isolated  LRU  failure  rates  and  those  isolated  in  groups  of  two  or 
more.  Verification  of  this  isolation  certainty  calculation  is  most  important 
since  this  is  the  prime  function  of  the  test  system. 
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3.4  ESTABLISHMENT  OF  TEST  CONFIGURATION 


After  data  from  each  of  the  suppliers  has  been  received,  reviewed,  and 
approved,  the  prime  contractor  test  system  design  group  has  the  responsibility 
of  integrating  the  various  aircraft  system  and  subsystem  tests  to  an  optimum 
configuration.  This  configuration  must  fulfill  not  only  the  performance  re¬ 
quirements  imposed  on  the  suppliers,  but  must  meet  the  overall  weapon  system 
requirements  as  well.  These  include  not  only  the  onboard  test  system  detection 
assurance  and  isolation  certainty  requirements  but  also  the  ability  of  the  test 
system  to  permit  the  availability  and  maintainability  requirements  of  the  weapon 
system  to  be  satisfied.  There  may  be  more  than  one  combination  of  tests  which 
can  qualify  in  meeting  or  exceeding  all  the  requirements,  in  which  case  further 
analysis  must  be  made  with  respect  to  cost  so  that  the  most  cost  effective 
arrangement  can  be  selected.  Even  so,  the  final  selection  must  be  approved 
by  the  Air  Force,  who  may  decide  that  certain  reductions  in  requirements  result 
in  a  more  cost  effective  test  configuration.  This  decision  or  acceptance  must 
be  made  by  the  Air  Force  before  documentation  can  be  completed  and  used  as  a 
basis  for  detailed  software  development. 

3.4.1  ALTERNATE  POSSIBILITIES 

Any  combination  of  tests  must  be  made  up  of  individual  tests  selected  in 
accordance  with  some  sheme  which  establishes  priorities.  Otherwise,  a  conglom¬ 
eration  of  tests  may  result  which  satisifies  quantitative  performance  require¬ 
ments  but  which  may  exclude  a  test  or  tests  vital  to  safety  of  flight  or  mission 
success. 

Obviously,  all  tests  involving  failure  modes  which  inpact  safety  of  flight 
must  be  included  mandatorily.  If  at  all  possible,  failure  modes  impacting  safe¬ 
ty  of  personnel,  safety  of  equipment,  and  mission  success  should  be  covered  by 
tests,  but  need  not  be  mandatory.  Overall,  the  priorities  of  tests  selected  for 
incorporation  should  be: 
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1.  Tests  for  failure  modes  impacting  safety  of  flight  (mandatory). 

2.  Tests  for  failure  modes  impacting  safety  of  personnel. 

3.  Tests  for  failure  modes  impacting  safety  of  equipment. 

4.  Tests  for  failure  modes  impacting  mission  success. 

5.  Tests  for  failure  modes  impacting  safety/ subsystem  performance. 

The  optimum  combination  of  tests  will  almost  certainly  not  include  all 

of  the  tests  listed  above,  but  for  the  purpose  of  providing  a  basis  for  com¬ 
parison  a  set  of  calculations  should  be  made  for  detection  assurance  (D)  and 
isolation  certainty  (I)  using  all  of  the  tests  devised.  Conformance  of  the 
calculated  D  to  the  availability  requirement  (A)  and  of  the  calculated  I  to 
the  maintainability  requirement  (M)  should  be  checked.  The  values  obtained 
for  D  and  I  will  be  the  maximum  attainable. 

Calculations  should  be  made  from  a  selected  group  of  tests  which  result 
in  minimum  allowable  values  for  D  and  I,  where  "allowable"  means  that  D,  I, 

A,  and  M  requirements  are  met  and  that  all  mandatory  tests  are  included. 

Other  combinations  of  tests  should  then  be  used  which  give  a  maximum  value 
for  D  with  a  minimum  allowable  I,  and  then  again  for  a  maximum  I  with  minimum 
allowable  D.  The  four  combinations  of  tests  resulting  from  the  foregoing  cal¬ 
culations  will  then  be  comprised  of  the  two  extremes  (maximum  and  minimum)  and 
two  combinations  of  the  two  extremes,  relative  to  the  two  basic  performance 
requirements  for  an  onboard  test  system  -  detection  assurance  and  isolation 
certainty.  From  these  four  sets  of  tests,  other  mixtures  can  be  derived  which 
compromise  the  extremes  to  various  degrees.  All  of  these  possibilities  are 
candidates  for  the  final  test  configuration,  subject  to  the  results  of  a  cost 
analysis. 

3.4.2  COST  ANALYSIS 

The  purpose  of  a  cost  analysis  is,  of  course,  to  determine  the  most  cost- 
effective  test  configuration.  This  involves  a  somehwat  detailed  comparison 
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of  development  exists,  production  costs,  and  support  cost  of  all  of  the  can¬ 
didate  test  configurations,  including  the  cost  of  any  TMDE  necessary  to  supple¬ 
ment  the  onboard  test  system  in  achieving  full  failure  detection  and  isolation 
capabilities.  The  cost  analysis  covers  the  period  of  time  from  the  beginning 
of  the  development  phase  to  the  end  of  the  contemplated  service  life  of  the 
test  system,  so  that  the  entire  life  cycle  is  considered. 

The  cost  model  recommended  for  use  in  determining  cost-effectiveness  of 
the  onboard  test  system  is  the  one  given  in  MIL-STD-1591  (On- Aircraft,  Fault 
Dignosis,  Subsystems,  Analysis/Synethesis  Of),  as  shown  below. 

Cost  =  C  +  NC,  +  C  +  ZC 

u  HP  aux  maux 

+  (1-PF)  [Np  PE  TZ  (M*L  +  M*y  ]  (C^) 

*  PF  <NF  »  PE  TZ)  t(WV  fW  *  CFD] 

+  Np  A  I  TZ  [CjFMV  ♦  (Cimp)  (<^11 

♦  N  TZ 

tTT  <**W  (W 


Where : 

Cp  =  Development  cost  of  the  onboard  test  system. 

N  =  Number  of  units  of  onboard  test  system  or  units  containing 
onboard  test  system  produced. 

Cp  =  Average  production  cost  of  onboard  test  system  (the  average 
cost  of  a  single  unit) • 

Caux  =  Total  cost  of  any  auxiliary  test  or  maintenance  equipment, 
external  to  onboard  test  system,  required  to  support  or 
complete  fundamental  onboard  test  system  tasks.  (For 
example,  a  supplemental  piece  of  test  equipment  necessary 
to  conplete  a  fault  isolation  task) . 
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Number  of  years  the  unit  onboard  test  system  is  contemplated 
to  be  in  service. 

Cost  per  year  of  maintaining  all  repaired  auxiliary  test  or 
maintenance  equipment. 

Proportion  of  prime  equipment's  faults  not  detected  by 
applicable  onboard  test  system. 

Average  number  of  units  of  onboard  test  system  or  units 
containing  onboard  test  system  in  field  use  at  any  time. 

Failure  rate  of  prime  equipment(s)  which  onboard  test  system 
serves  (does  not  include  failure  rate  of  ports  belonging 
uniquely  to  onboard  test  system) ,  in  failures  per  flight  hour. 

Flight  hours/unit  onboard  test  system/year 

Average  maintenance  manhours  required  for  initial  fault  detection 
and  isolation  by  onboard  test  system  (NOTE:  If  fault  detection 
and  isolation  is  fully  automatic,  XML  =  0). 

Average  maintenance  manhours  required  for  secondary  isolation 
(to  determine  which  is  the  malfunctioning  LRU  in  those  cases 
where  initial  isolation  is  ambiguous) . 

Cost  per  liaintenance  manhour. 

Average  maintenance  manhours  required  for  manual  troubleshooting 
to  isolate  to  an  LRU  in  those  cases  where  a  failure  is  not  detected 
by  the  onboard  test  system. 

Average  cost  to  determine  that  a  failure  has  occurred. 

Failure  rate  of  onboard  test  system. 

Average  cost  per  onboard  test  system  failure  (material,  spares,  etc.). 

Average  number  of  manhours  required  to  repair  an  onboard  test  system 
failure. 

Flight  hours  between  preventive  maintenance  actions  for  onboard  test 
system. 
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^PM  =  Average  maintenance  manhours  per  onboard  test  system  preventive 
maintenance  action. 

The  cost  model  elements  can  be  identified  and  more  simply  defined  as 
follows : 

1.  Cost  of  development. 

2.  Average  cost  of  production  unit. 

3.  Cost  of  TMDE. 

4.  Cost  of  maintaining  TM)E. 

5.  Cost  of  manhours  for  failure  detection  (detectable  failures). 

6.  Cost  of  manhours  for  failure  isolation  (detectable  failures). 

7.  Cost  of  manhours  for  failure  detection  (nondetectable  failures). 

8.  Cost  of  manhours  for  failure  isolation  (nondetectable  failures) . 

9.  Cost  of  maintaining  onboard  test  system. 

10.  Cost  of  preventive  maintenance  on  onboard  test  system. 

It  is  apparent  that  the  costs  are  basically  those  related  to  the  cost  of 
hardware  (test  system,  TMDE,  spare  parts)  and  to  the  cost  of  maintenance  man¬ 
power.  Reductions  in  cost  can  only  take  place  in  these  two  general  areas. 
Normally,  an  increase  in  the  capability  of  an  onboard  test  system  to  detect 
and  isolate  failures  could  be  expected  to  increase  the  cost  of  developing  and 
producing  the  test  system  hardware,  while  reducing  the  cost  of  TMDE  (less  TMDE 
required)  and  maintenance  actions.  Thus,  the  cost  comparison  of  an  existing 
onboard  test  system  to  an  improved  system  is  less  likely  to  show  a  dramatic 
cost  savings  than  is  the  comparison  of  a  ground  test  concept  to  an  onboard 
test  system. 

A  study  of  the  cost  effectivity  of  an  advanced  version  of  CITS  for  the 
B-l  aircraft  versus  a  grouid  test  system  to  accomplish  the  same  level  of  testing 
showed  that  for  111  aircraft  over  a  period  of  20  years,  a  total  of  $293,120,000 
would  be  saved  by  installing  the  CITS.  It  was  found  that  the  lower  cost  of  the 
CITS  approach  was  primarily  due  to  the  fact  that  fault  detection  and  fault  iso¬ 
lation  testing  is  performed  in  parallel  with  normal  flight  operations  wherein 


the  ground  test  concept  requires  ground  operating  time  to  test  and  determine 
the  health  of  the  aircraft.  This  additional  ground  test  time  significantly 
increases  aircraft  system  operating  time,  thereby  increasing  aircraft  hardware 
failures.  The  cost  of  this  additional  testing  time  (maintenance  manhours)  and 
the  repair  and  replenishment  cost  of  aircraft  spares  contributed  more  than  60 
percent  of  the  cost  difference. 

3.4.3  FINAL  SELECTION 

After  the  various  alternate  possibilities  of  test  configurations  have  been 
compared  by  cost  analysis,  the  one  configuration  which  comes  out  as  most  cost 
effective  would  normally  be  documented  and  implemented .  However,  the  cost 
differentials  may  be  small  enough  to  warrant  consideration  of  one  or  more  of 
higher  detection  assurance,  higher  isolation  confidence,  greater  availability, 
or  better  maintainability.  In  other  words,  the  customer  may  be  willing  to  pay 
a  little  more  for  increased  performance  benefits.  Therefore,  the  customer  must 
be  fully  apprised  of  the  results  of  all  cost  analysis  and  alternate  configuration 
capabilities  so  that  the  final  selection  is  either  made  by  him  or  receives  his 
total  approval. 

3.5  DOCUMENTATION 

After  the  process  of  evaluating  functional  requirements,  specifying  these 
requirements  for  procurement,  evaluating  supplier  responses,  and  making  a  final 
selection  of  a  test  configuration  has  been  completed,  the  results  must  be  doc¬ 
umented. 

To  be  of  maximum  utility,  documentation  must  be  carefully  assembled  so  that 
the  total  test  configuration  description  is  not  only  complete  and  accurate,  but 
is  presented  in  a  clear  and  logical  manner.  Even  though  separate  documents  will 
be  prepared  describing  test  system  hardware,  aircraft  subsystem  hardware,  test 
software,  and  support  equipment,  it  should  be  kept  in  mind  that  the  readers  of 
the  test  requirements  document  will  include  those  with  widely  varying  interests. 
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Primarily,  the  information  would  be  of  greatest  interest  to  the  software 
designers  who  must  translate  the  test  requirements  into  a  software  program. 
However,  portions,  if  not  all,  of  the  information  would  most  certainly  prove 
to  be  helpful  to  maintenance  personnel,  aircraft  subsystem  designers,  logistics 
personnel,  TMDE  designers,  flight  crews,  flight  test  analysts,  and  customer 
personnel  involved  in  the  evaluation  of  not  only  the  onboard  test  system  but 
of  the  aircraft  subsystems  as  well. 

3.5.1  CONTENT 

The  basic  content  of  the  test  requirements  document  will  be  a  description 
of  the  test  configuration.  This  configuration  consists  of  the  individual  tests 
selected  as  necessary  to  satisfy  the  functional  requirements.  However,  the 
presentation  of  this  information  necessarily  requires  various  types  and  quan¬ 
tities  of  other  supporting  information.  It  is  recommended  that  this  supporting 
information  be  such  that  a  complete  background  of  the  reasoning  and  processes 
leading  to  the  selection  of  the  particular  tests  is  provided,  as  well  as  an 
explanation  of  the  theory  and  structuring  of  the  tests  themselves.  This  may 
include  block  diagrams,  perspective  drawings,  equations,  schematics,  wiring 
diagrams,  illustrations,  and  logic  diagrams.  Care  should  be  taken  to  confine 
the  use  of  these  types  of  supporting  data  to  only  those  portions  pertinent  and 
directly  applicable  to  avoid  confusing  the  reader  with  unnecessary  or  unimpor¬ 
tant  facts. 

A  description  of  the  aircraft  subsystem  under  test  should  be  included  to 
provide  the  reader  with  an  understanding  of  the  physical  aspects  of  the  sub¬ 
system  and  the  functions  and  operation  of  the  subsystem,  including  the  sub¬ 
system  performance  criteria  used  in  developing  the  tests  selected.  This  would 
then  support  a  description  of  the  test  approach  and  rationale,  which  would 
follow. 

An  actual  explanation  of  each  test  should  be  given  in  the  text,  following 
the  same  sequence  as  is  used  in  the  test  logic  diagram.  The  test  logic  dia¬ 
gram  is  a  pictorial,  or  diagrammatic,  representation  of  the  tests  encompassing 
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the  test  requirements.  This  type  of  presentation  is  described  in  paragraph 
3. 2. 2. 4.4  of  Section  3  and  illustrated  by  figure  3-9. 

The  use  of  the  test  logic  diagrams  requires  a  list  of  the  aircraft  sub¬ 
system  LRU's  and  a  list  of  the  test  parameters  associated  with  the  particular 
tests.  These  lists  are  described  and  illustrated  in  Section  3  (paragraphs 
3.2. 2. 4. 2.1  and  3. 2. 2. 4. 3). 

3.5.2  FORMAT 

Normally,  the  quantity  of  information  to  be  included  in  the  documentation 
of  test  requirements  would  preclude  the  use  of  a  single  document  for  the  overall 
aircraft  test  configuration.  It  is  recomnended  that  the  documentation  be  pre¬ 
pared  in  separate  volumes,  each  of  which  addresses  the  testing  of  a  single  air¬ 
craft  subsystem. 

The  sequence  of  presentation  of  the  contents  of  each  volume  should  be  the 
same  and  should  follow  a  logical  pattern.  Based  on  the  content  described  in 
the  previous  paragraph,  it  is  recomnended  that  the  following  format  be  used: 

A.  Aircraft  Subsystem  Description 

1.  Function 

2 .  Performance 

3.  Operation 

B.  Test  Approach 

1.  Basic  Subsystem  Test  Requirements 

a.  Criteria 

b.  Rationale 

2.  Test  System  Application 

a.  LRU  list 

b.  Parameter  List 

c.  Failure  Detection  Tests 

d.  Fault  Isolation  Tests 

e.  Test  Logic  Diagrams 
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Although  the  parameter  list  could  be  included  as  a  part  of  each  volume, 
it  is  felt  that  a  separate  document  listing  all  test  parameters  for  the  entire 
aircraft  test  configuration  would  be  of  greater  use.  Therefore,  a  reference 
to  such  a  document  in  each  separate  test  requirement  document  would  replace 
the  parameter  list. 

3.6  SUMARY 

The  development  of  a  set  of  tests  to  be  conducted  by  an  onboard  test 
system  involves  an  orderly  process  whereby  given  tasks  are  conducted  and 
accomplished  in  an  established  sequence.  The  process  involves  four  basic 
tasks:  1)  Evaluation  of  functional  requirements,  2)  Specification  of  require¬ 
ments  for  subcontractors  and  suppliers,  3)  Evaluation  of  subcontractor/supplier 
data,  and  4)  Documentation  of  the  final  test  configuration.  The  first  two 
tasks  require  separate  examinations  of  the  requirements  imposed  on  the  onboard 
test  system  and  of  the  requirements  impacting  the  design  of  aircraft  systems 
interfacing  with  the  test  system.  Candidate  test  configurations  are  derived 
from  data  submitted  by  subcontractors/suppliers,  after  which  the  contractor 
conducts  cost  analyses  on  each  alternate  configuration  prior  to  selecting  and 
recommending  a  final  configuration  for  the  customer's  consideration/approval. 
Agreement  on  the  test  configuration  to  be  implemented  prefaces  the  task  of 
documentation,  whereby  not  only  are  the  tests  described,  but  relevant  infor¬ 
mation  is  presented  to  give  an  insight  into  the  process  and  reasoning  behind 
the  formulation  of  an  optimum  test  selection. 

Appendix  D,  "B-l  CITS  Implementation  Summary",  is  provided  as  a  qualitative 
evaluation  of  test  mechanizations  resulting  from  the  OBTS  requirements  analysis 
process . 
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Section  4 

TEST  SYSTEM  HARDWARE  DESIGN 

4.1  DERIVATION  OF  DESIGN  REQUIREMENTS 

When  implementing  an  onboard  test  system,  design  of  the  test  system  hard¬ 
ware  and  its  interface  with  the  various  subsystems  under  test  must  be  defined, 
developed,  and  implemented  in  parallel  with  the  development  of  the  prime  weapon 
system.  The  test  system  hardware  must  provide  the  basic  functions  of  acqui¬ 
sition,  processing,  and  dissemination  of  the  test  data.  The  test  system  de¬ 
signer  has  to  determine  what  analyses  and  various  trade  studies  are  needed  to 
select  hardware,  or  combination  of  hardware,  to  best  suit  each  of  the  three 
basic  test  functions  for  his  particular  application.  In  addition,  the  test 
system  designer  must  determine  what  test  parameters  are  needed  to  perform  the 
test  functions  and  how  the  test  system  will  be  mechanized  to  access  the  test 
data.  When  needed  test  signals  are  not  available  to  the  test  system,  the 
designer  must  add  these  interfaces  to  the  weapon  system  through  the  addition 
of  unique  test  sensors.  When  selecting  existing  test  signals  or  when  adding 
new  test  interfaces  the  test  technique  should,  when  possible,  utilize  test 
parameters  that  provide  more  than  one  piece  of  test  data.  The  test  technique 
should  also  make  use  of  available  operational  signals  to  the  maximum  extent 
possible.  Finally,  the  designer  must  consider  what  test  techniques  and  hard¬ 
ware  best  supports  testing  of  off-the-shelf  hardware  utilized  by  the  sub¬ 
systems  under  test  and  what  test  techniques  and  interfaces  should  be  imple¬ 
mented  in  hardware  being  newly  designed,  or  modified,  for  the  weapon  system. 

4.1.1  GENERAL  HARDWARE  DESIGN  PHILOSOPHY 

The  following  represents  general  hardware  design  philosophies  which  the 
designer  should  utilize  when  analyzing  and  performing  trade  studies  to  develop 
an  onboard  test  system. 


I 

\ 
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1.  Input/Output  Signal  Isolation 

The  onboard  test  system  should  be  isolated  from  the  system  under 
test  to  insure  that  any  failure  in  the  test  system  will  not  prop¬ 
agate  to  the  system  under  test  and  interface  with  the  functional 
operation. 

2.  Stimulus  Signals 

Test  stimuli  should  be  at  minimum  levels  to  insure  that  there  are 
no  extraneous  system  responses,  other  than  expected. 

3.  Interface  Circuitry 

Whenever  possible  existing  interfaces  should  be  utilized  in  order 
to  minimize  the  added  test  circuitry  impact  on  the  systems  under 
test. 

4.  Common  Test  Points 

Optimization  of  testing  is  enhanced  by  the  selection  of  test  points 
that  provide  multiple  test  parameters.  This  will  minimize  the  input/ 
output  circuitry  of  the  test  mechanization. 

5.  Test  Hardware  Reliability 

The  reliability  of  the  test  hardware  should  exceed  the  reliability 
of  the  system  under  test.  If  this  is  not  done  the  occurrence  of 
failures  in  the  test  circuitry  could  exceed  the  number  of  failures 
occurring  in  the  system  under  test. 

6.  Test  Hardware  Simplicity 

The  test  hardware  complexity  should  be  minimized  in  order  to  reduce 
the  probability  of  failure  and  increase  reliability. 

7.  Maintainability 

This  factor  affects  cost,  weight,  and  the  physical  characteristics 
of  the  entire  test  system.  Affected  physical  characteristics  include: 

A.  Coupling  requirements  for  power  and  cooling. 

B.  Access  of  the  black  boxes  of  the  test  system  by  maintenance 
personnel. 
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C.  Ease  of  replacing  used  materials  such  as  lighting  elements, 
recorder  tape  cartridges,  and  hardcopy  printer  paper. 


4.2  TEST  SYSTEM  CONTROL 

The  test  system  must  have  the  means  of  controlling  the  processing  of  test 
data  and  performing  the  logical  steps  developed  to  to  test  the  aircraft  sub¬ 
system.  Within  the  context  of  this  design  guide,  system  level  implementation 
is  provided  and  is  not  to  be  interpreted  as  LRU  BIT  which  is  discussed  in 
many  other  design  guides  written  on  that  subject.  Basically,  theTe  are  two 
general  approaches  to  test  system  control:  (1)  with  a  centralized  computer 
system  or  (2)  with  a  distributed  computer  system.  The  following  discusses 
these  two  methods  with  regards  to  the  advantages,  disadvantages,  and  selection 
guidelines. 

Although  the  centralized  and  distributed  computer  system  approaches  are 
each  discussed  below,  it  must  be  noted  that  a  combination  of  these  approaches 
may  be  the  optimum  solution  in  a  particular  application.  This  is  especially 
true  when  some  systems  under  test  require  a  dedicated  computer  for  functional 
purposes. 

4.2.1  TYPES 

4. 2. 1.1  Centralized  Test  Control 

The  centralized  test  system  control  involves  the  use  of  a  central  computer 
or  processor  which  has  total  control  over  the  test  system  operation.  The 
central  computer  tells  the  devices  used  for  data  acquisition  what  data  to 
access  and  when  to  send  the  data  to  the  computer.  It  also  directs  and  con¬ 
trols  the  devices  used  to  transmit  the  data  to  the  system  operator  and  data 
storage  devices.  Finally,  the  central  processor  has  stored  within  its  memory 
real-time  test  programs  for  analyzing  aircraft  system  operation  and  determining 
when  a  system  is  malfunctioning. 
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The  following  discusses  some  of  the  more  important  advantages  and  dis¬ 
advantages  of  designing/implementing  a  centralized  approach  to  onboard  testing. 

4. 2. 1.1.1  Advantages 

4. 2. 1.1. 1.1  Conservation  of  Software.  The  number  of  software  instructions 
needed  are  reduced  in  the  centralized  test  approach  because  the  executive 
and  control  programs  are  shared  by  all  of  the  test  programs,  therefore  reduc¬ 
ing  time  and  money  expenditures  in  developing  and  maintaining  one  main  soft¬ 
ware  program  versus  several  individual  programs  required  by  a  distributed 
type  system. 

4 . 2 . 1 . 1 . 1 . 2  Test  Mechanization  Placement.  The  centralized  test  approach 
enables  the  transfer  of  the  test  mechanization  from  the  individual  system 
LEU,  which  may  use  hardwired  or  PROM  test  logic,  into  the  test  system  com¬ 
puter.  This  reduces  the  circuitry  in  these  devices  to  what  is  necessary 
for  operational  functions  and  the  provisions  to  provide  conditioned  test 
parameters  to  the  test  system.  The  reduction  in  circuitry  ultimately  reduces 
the  weight  of  the  system/LRU  while  increasing  the  system/LKU  reliability. 

In  addition,  if  the  test  circuitry/logic  is  hardwired  in  the  LRU,  changes 
to  the  device  are  more  costly  and  require  much  longer  time  spans  to  incor¬ 
porate.  During  the  initial  definition  of  the  B-l  CITS,  a  study  was  conducted 
on  the  Mark  II  avionics  system  to  determine  its  effect  on  centralized  testing. 
It  was  determined  that  implementing  the  test  logic  within  the  Mark  II  hardware 
would  cause  as  much  as  a  30  percent  increase  in  weight  and  a  resultant  decrease 
in  reliability  of  18  percent.  When  the  centralized  concept  was  examined  rel¬ 
ative  to  Mark  II  hardware  inpact,  it  was  determined  that  the  circuitry  required 
to  access  and  condition  the  test  parameters  for  CITS  testing  purposes  added 
approximately  a  S  percent  increase  in  weight  and  a  resultant  decrease  in  reli¬ 
ability  of  3  percent. 
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4.2.1. 1.1.3  Technical  Risk.  During  the  development  of  the  systems  under  test 
many  problems  arise  and  full  attention  has  to  be  given  to  their  solution.  If 
the  test  logic  function  is  contained  in  each  subsystem,  many  system/test  logic 
interrelated  problems  could  arise  which  would  increase  the  technical  risk  of 
the  timely  advancement  of  both  the  test  system  and  operational  system  devel¬ 
opment.  By  limiting  only  test  parameters  to  be  implemented  into  the  system 
design,  and  not  test  logic  circuitry,  development  of  both  systems  can  be  done 
relatively  in  parallel  with  one  another. 

4. 2. 1.1. 1.4  Common  Test  Control/Systems  Status  Panel.  The  centralized  ap¬ 
proach  affords  the  design  option  of  using  a  common  test  control/systems  status 
panel  presentation  of  all  system  statuses  to  the  flight  crew.  In  a  distributed 
BIT  system  the  failure  indications  are  displayed  on  multiple  control/ status 
panels  distributed  throughout  the  crew  station.  The  distributed  display  con¬ 
figuration  would  make  a  quick-look  system  status  capability  difficult. 

4. 2. 1.1. 1.5  Equipment  Additions.  The  centralized  test  approach  utilization 
of  a  common  data  bus  affords  the  designer  the  options  of  easily  adding  failure 
maintenance  data  storage  devices,  hardcopy  printers,  and  additional  DAD's  if 
the  test  requirements  warrant  them. 

4. 2. 1.1. 2  Disadvantages 

The  one  disadvantage  with  the  centralized  approach  is  the  need  to  pre- 
process  (i.e.,  change  the  order  of  the  parameters  in  the  computer  memory  to 
be  able  to  perform  the  software  tests  in  an  optimum  manner) .  The  parameter 
order  in  the  computer  is  dictated  by  the  order  in  which  the  signals  are  wired 
to  the  DAD.  The  wiring  of  signals  to  the  DAD  is  dependent  on  system  location 
in  the  aircraft,  density  of  signals  to  be  acquired  from  any  one  location,  and 
accessibility  of  a  DAD  in  that  location.  There  are  two  solutions  to  this 
problem. 
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1.  Perform  system-by- system  planning  of  test  interface  requirements 
to  the  DAD  to  minimize  preprocessing  requirements  by: 

A.  Assignment  of  DAD  input/output  channels  to  minimize  need  to 
reorder  data. 

B.  Placement  of  DAD  to  optimize  pin  assignments  to  input  channels 
to  the  test  system. 

2.  Off-load  the  central  computer  task  of  parameter  reordering  to  the 
DAD  by  the  incorporation  of  a  microprocessor  in  the  DAD. 

4. 2. 1.2  Distributed  Test  Control 

Distributed  test  system  control  differs  from  centralized  control  in  that 
all  of  the  comnon  functions,  such  as  data  acquisition,  scaling,  parameter  iso¬ 
lation,  processing,  and  failure/system  status  display,  have  to  be  incorporated 
or  duplicated  in  each  system  under  test.  This  conparison  is  illustrated  in 
Figure  4-1.  Although  there  is  test  hardware  duplication  in  the  distributed 
approach,  there  are  certain  advantages  to  this  type  of  mechanization. 

4 . 2 . 1 . 1 . 2 . 1  Advantages 

When  hardware  test  logic  is  used,  test  data  aging  is  minimized  because 
the  acquisition  time  is  minimized  due  to  the  signals  being  isolated,  scaled, 
and  directly  fed  into  the  LRU  logic  circuitry. 


4. 2. 1.2. 2  Disadvantages 


Distributed  Versus Centralized  Onboard  Test  Philosophies 

Figure  4-1 


4. 2. 1.2. 2.1  Weight.  The  weight  increase  for  the  distributed  approach  is  usually 
greater  than  for  the  centralized  case.  Both  techniques  require  that  test 
signals  be  conditioned,  scaled,  and  isolated.  In  the  centralized  case  these 
would  be  done  within  the  system  LRU  and  fed  into  the  central  computer  via 

DAD's  for  processing,  utilizing  common  software  and  hardware.  The  distri¬ 
buted  system  would  require  repeated  hardware/software  logic  and  display  appa¬ 
ratus  to  be  added  to  each  system  to  accomplish  the  test  function,  thus  adding 
a  greater  complexity  to  each  system  LRU. 

4. 2. 1.2. 2. 2  Failure  Analysis.  The  distributed  test  approach  inhibits  main¬ 
tenance  failure  analysis.  The  functional  parameters  utilized  by  the  BIT  are 
usually  unavailable  for  data  recording  purposes,  which  decreases  the  effec- 
tivity  of  a  maintenance  ground  processing  system  prediction  of  incipient  fail¬ 
ures.  By  eliminating  this  prediction  capability  maintenance  action  cannot 
occur  before  failure  of  the  LRU  for  those  systems  where  failure  predicting/ 
trending  is  feasible. 

4. 2. 1.2. 2.3  Logic  Changes.  If  the  distributed  system  u<.t>-  ed  hardware  logic 
to  perform  the  test  function,  changes  to  the  test  logic  would  be  very  costly 
and  time  consuming. 

4.2.2  SELECTION  GUIDELINES 

The  task  of  selecting  a  centralized  test  system  or  a  distributed  one 
involves  many  trade  studies  and  evaluations.  Items  to  be  considered  are 
discussed  in  the  following  paragraphs. 

4. 2. 2.1  Weight 

The  designer  must  estimate  the  total  weight  impact  of  each  type  of  testing 
scheme  and  decide  which  has  the  advantage  in  his  application. 


4. 2. 2. 2  Cost 


Cost  trade  studies  are  required  to  determine  which  approach,  centralized 
or  distributed,  provides  minimum  total  costs,  including  flyaway  and  life  cycle, 
and  still  meets  contract  requirements. 

4. 2. 2. 3  Reliability 

The  reliability  factors  are  the  most  nebulous  of  all  the  considerations 
made.  The  designer  will  have  to  get  his  estimates  from  people  who  specialize 
in  the  area  of  reliability  and  weigh  this  against  what  the  alternatives  are 
for  not  adding  test  circuitry  to  his  operational  black  box. 

4. 2. 2. 4  Implementation  Time 

The  designer  will  have  to  estimate  the  total  design,  development,  and 
testing  times  necessary  for  each  test  technique  and  compare  this  to  his  total 
aircraft  development  schedule  for  feasibility. 

4. 2. 2. 5  Air  Crew 

The  air  crew  has  limited  time  to  status  system  health.  The  designer 
would  have  to  estimate  the  time  constraints  in  this  area  and  decide  which 
method  complies  with  the  needs  of  the  air  crew. 

4. 2. 2. 6  Space  Availability 

For  either  of  the  two  test  methods  discussed,  centralized  or  distributed, 
these  would  be  a  delta  to  space  usage.  The  designer  would  have  to  estimate 
the  space  required  by  both  methods  and  compare  this  to  the  space  available. 

4. 2. 2. 7  Support  Equipment  (SE) 

The  type  of  SE  procured  for  field  operations  purposes  would  differ  de¬ 
pending  on  what  type  of  test  system  is  implemented.  These  pieces  of  equipment 


and  their  usage  are  part  of  the  overall  maintenance  plan  which  is  specified 
by  the  contractor. 

4. 2. 2. 8  Contractor  Requirements 

In  some  instances  the  contractor  may  dictate  to  the  designer  certain 
required  capabilities.  These  all  have  to  be  analyzed  and  traded  off  with 
the  previously  discussed  factors  and  presented  to  the  contractor  for  approval. 

4.3  DISPLAY 

An  onboard  test  system  acquisitions  data,  performs  tests,  and  displays 
the  results  for  the  flight  and  maintenance  crew.  The  presentation  of  test 
results  to  the  crew  requires  means  for  providing  clear  and  easily  under¬ 
standable  descriptions  of  detected  faults  by  the  onboard  test  system.  Display 
devices  available  vary  from  single  light  emitting  devices,  with  display  mes¬ 
sages  engraved  on  the  surface,  to  large  cathode  ray  tubes  presenting  full  page 
alphanumeric  messages  or  symbols.  The  display  is  subject  to  standards  for 
human  interface  requirements  which  include  visibility,  color,  standard  abbre¬ 
viations  (language) ,  techniques  of  interaction  with  manual  controls,  operation 
position,  available  space,  and  systems  environmental  conditions  such  as  ambient 
light,  vibration,  and  temperature. 

4.3.1  TYPES 

In  this  section  two  types  of  displays  will  be  discussed:  1)  a  dedicated 
legend  display  such  as  used  on  the  B-l  CITS  system  and  2)  a  cathode  ray  tube 
display.  A  description  of  the  B-l  CITS  display  is  provided  for  the  first  dis¬ 
play  type  and  the  reasons  for  choosing  the  display  elements  are  given. 

4.3. 1.1  CITS  Control  and  Display  Panel  (CCD) 

The  following  presents  a  description  of  the  CCD  (see  Figure  4-2)  pro¬ 
vided  for  the  B-l  aircraft  in  order  to  comply  with  the  contract  requirement 
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of  displaying  the  aircraft  status  to  the  crew  continuously  during  aircraft 
operation  both  in-flight  and  on  the  ground. 

A  CCD,  located  in  the  aft  crew  station,  is  provided  as  part  of  the  CITS 
subsystem.  The  CCD  simultaneously  indicates  status  of  the  subsystems  and/or 
modes  of  operation  of  the  subsystems  while  in-flight  or  on  the  ground.  Sub¬ 
system  operation  outside  of  performance  limits  is  indicated  by  illuminating 
a  visual  display  and  subsystem  operation  within  performance  limits  is  indi¬ 
cated  by  the  absence  of  a  visual  display.  No  special  catalogs  or  handbooks 
are  required,  and  no  understanding  of  special,  complex  coded  language  required 
of  the  crew  to  interpret  the  CITS  status  display.  The  display  is  sized  to 
accommodate  air  vehicle  and  avionics  subsystem  status  with  a  10  to  15  percent 
growth  capability.  Controls  are  provided  for  mode  selection  and  display  con¬ 
trol.  Capability  to  reset  the  illuminated  legends  by  the  crew  is  also  pro¬ 
vided.  A  multipurpose  alphanumeric  display  is  provided  for  readout  of  per¬ 
tinent  maintenance  information  in  abbreviated  English  messages.  Control  is 
provided  for  active  ground  testing  of  each  aircraft  subsystem  by  insertion 
of  a  system  test  code  through  a  data  entry  keyboard.  Preflight  data,  (such 
as  tail  number,  engine  serial  number,  aircraft  data,  etc.)  is  inserted  by 
keyboard  entry  prior  to  flight  for  entry  onto  the  maintenance  recorder  and 
hardcopy  printer  for  tracking  purposes. 

The  description  given  for  the  CITS  CCD  provides  an  example  of  a  device 
which  includes  several  different  methods  of  man-machine  interfaces.  The  first 
is  the  illumination  of  an  engraved  message  panel  to  convey  the  failure  message 
to  the  operator  This  method  is  the  most  commonly  used  technique,  in  mil¬ 
itary  aircraft,  to  communicate  caution  and  warning  to  pilots.  The  second 
technique  utilized  is  the  alphanumeric  display  which  used  incandescent  type 
elements  to  make  up  the  individual  letters.  The  rationale  for  using  an  incan¬ 
descent  device  in  lieu  of  Light  Emitting  Diodes  (LED)  is  that  the  LED's  are 
only  available  in  colors  of  red  and  green,  while  human  factors  requirements, 
as  specified  in  MIL-STD-1472,  requires  amber  colored  lighting  to  be  used. 
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In  general,  when  requirements  demand  restricted  weight,  low  power  consump¬ 
tion,  capability  of  being  visible  in  direct  sunlight,  and  high  reliability, 
LED  display  devices  should  be  chosen  where  color  is  not  a  factor.  When  the 
incandescent  light  elements  were  chosen  for  the  dedicated  legend  displays 
to  meet  the  color  requirements  they  were  designed  to  utilize  two  bulbs  per 
device  so  that  a  single  filament  failure  would  not  cause  loss  of  the  failure 
indication.  The  alphanumeric  display  was  made  up  of  many  incandescent  ele¬ 
ments  creating  the  numbers  or  letters.  It  was  felt  that  when  one  element  of 
the  letter  or  number  was  lost,  improper  interpretation  by  the  crew  would  be 
at  a  minimum,  therefore  dual  elements  were  not  utilized.  The  third  type  of 
interface  device  used  was  switches  (on/off,  mode  selection,  and  pushbutton 
matrices) .  These  devices  give  the  operator  control  of  the  system  operation. 
For  the  CITS  application  the  mechanical  contact  type  devices  were  chosen  be¬ 
cause  when  inputting  data  into  the  system,  the  operator  would  receive  feed¬ 
back  that  his  individual  actions  have  been  completed  in  that  he  can  feel  con¬ 
tact  was  made  in  the  switch. 

The  CITS  CCD  exemplified  a  dedicated  onboard  test  display  panel  which 
poses  two  advantages.  The  major  advantage  to  using  the  dedicated  type  of 
display  is  the  ability  to  provide  redundancy  where  a  single  filament  failure 
will  not  cause  loss  of  the  failure  indication.  The  second  advantage  is  that 
a  total  aircraft  status  is  displayed  at  all  times  similar  to  a  caution  and 
warning  panel. 

4. 3. 1.2  Cathode  Ray  Tube  (CRT) 

In  the  area  of  information  output  the  CRT  device  has  a  higher  density 
of  data  per  a  specified  space  than  any  other  known  device  and  does  not  have 
to  be  physically  modified  to  accomnodate  minor  changes  in  the  test  system  out¬ 
put  requirements.  A  disadvantage  with  CRT's  is  that  the  electronics  which 
supply  it  information  is  more  complex,  therefore  subject  to  higher  failure 
rates  than  those  supplying  information  to  a  device  such  as  the  B-l  CITS  CCD. 
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Another  disadvantage  with  the  CRT  is  the  total  loss  of  display  with  a  single 
failure  in  the  CR  tube. 


The  CRT  device  is  basically  developed  from  vacuum  tube  technology.  The 
basic  nine  inch  (diagonal)  CRT  requires  approximately  ten  thousand  volts  to 
illuminate  the  screen,  which  produces  electromagnetic  fields,  possibly  affect¬ 
ing  instruments  onboard  the  aircraft.  These  effects  are  controllable  by  in¬ 
corporating  shielding  material  around  the  high  voltage  power  supply  and  CRT. 
These  disadvantages  should  not  be  taken  to  supersede  the  fact  that  the  most 
flexible  choice  for  an  output  device  would  be  a  CRT. 

When  designing  the  display  for  an  onboard  test  system  the  designer  would 
have  to  perform  trade  studies  to  be  able  to  choose  between  a  multifunction 
device  such  as  a  CCD  and  single  function  (display)  device  such  as  a  CRT.  The 
designer  would  have  to  analyze  the  trades  concerning  weight,  cost,  volume, 
power  consumption,  and  software  coding  necessary  to  perform  the  display  func¬ 
tion. 


4.3.2  SELECTION  GUIDELINES  FOR  DISPLAYS 

4. 3. 2.1  Aircraft  Type 

The  aircraft  type  and  operational  requirements  would  influence  the  dis¬ 
play  requirements  for  the  onboard  test  system.  A  test  system  being  developed 
for  a  small  aircraft  may  only  require  priority  coded  failure  data  to  be  pres¬ 
ented  to  the  pilot  and  therefore  could  timeshare  an  existing  multifunction 
display  with  other  aircraft  systems.  A  larger,  more  complex  aircraft  may 
require  a  dedicated  display  to  provide  continual  aircraft  system  status.  If 
the  aircraft  is  required  to  operate  out  of  austere  and  dispersed  bases,  the 
control  and  display  device  chosen  must  acconmodate  both  flight  and  ground 
crew  usage  by  displaying  system  failures  to  the  flight  crew  to  determine  re¬ 
maining  mission  capability  and  maintenance  data  relating  to  maintenance  ac¬ 
tions  required  by  the  ground  crew.  In  order  to  determine  the  method  of  display 
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best  suited  for  a  particular  application,  analysis  and  trade  studies  need  to 
be  conducted  with  respect  to  the  following  elements: 

A.  Operating  environment  of  the  display. 

B.  Operational  requirements  of  the  aircraft. 

C.  Amount  of  data  to  be  displayed  at  one  time. 

D.  Contract  requirements  for  the  display. 

E.  Format  and  content  of  displayed  data. 

F.  Reliability  of  display  device  chosen. 

G.  Effect  of  failures  on  display  requirements. 

H.  Advantages/disadvantages  of  time  sharing  displays  with  other 
aircraft  systems. 

I.  Human  factor  requirements  such  as  cone  of  vision  and  crew  access. 

4. 3. 2. 2  Space  Allocation 

The  available  space  for  the  test  system  control  and  display  device  in 
combination  with  the  amount  and  format  of  the  data  that  must  be  displayed 
to  the  user,  highly  influences  the  type  of  display  selected.  If  the  space 
is  limited,  the  designer  needs  to  select  the  display  device  that  affords 
him  sufficient  flexibility  in  its  display  output.  This  requirement  could  be 
met  with  a  multifunction  display,  an  alphanumeric  display,  or  a  CRT  display. 
The  designer,  therefore,  must  trade  off  the  different  options  available  to 
him  that  can  be  accommodated  in  his  allocated  space  and  select  the  one  that 
is  most  effective. 

An  example  of  a  space  allocation  trade  study  is  the  following: 

In  the  original  design  concepts  of  the  B-l  CITS,  two  displays  were  plan¬ 
ned:  1)  a  crew  status  display  and  2)  a  maintenance  control  and  status  panel. 
Analysis  showed  that  a  large  nunber  of  functions  were  common  to  both  panel 
requirements.  A  cost  and  weight  trade  study  was  conducted  to  determine  the 
effect  of  providing  a  single  panel  for  both  flight  and  maintenance  crew  usage. 
The  study  indicated  that  for  a  slight  increase  in  crew  station  panel  space 
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allocation,  significant  savings  in  cost  and  weight  could  be  realized.  As  a 
result  of  this  study,  the  panel  space  allocation  was  increased  and  both  panel 
functions  were  combined  into  a  single  panel. 

4. 3. 2. 3  Human  Engineering  Requirements 

The  human  engineering  requirements  carry  a  high  priority  when  designing 
equipment  where  man-machine  interfaces  are  involved.  Human  engineering  require¬ 
ments  have  to  be  accounted  for  in  the  selection  and  final  design  of  the  display 
device.  Human  engineering  requirements  include: 

1.  Panel  legend  design. 

2.  Cone  of  vision  of  crew  to  display  panel. 

3.  Crew  reach  access  to  panel. 

4.  Size  and  shape  of  pushbutton  and  switches. 

5.  Color  and  brightness  of  displays. 

4. 3. 2. 4  User  Skill  Level  Requirements 

User  level  requirements  represent  those  guidelines  defining  the  intelli¬ 
gence,  training,  and  experience  of  the  user  of  the  test  system.  These  require¬ 
ments  play  an  important  role  in  the  design  of  the  display  in  a  manner  of  set¬ 
ting  the  ground  rules  for  establishing  the  content  and  overall  configuration 
of  the  display  such  that  the  information  presented  can  be  easily  understood 
by  the  user  level  specified  by  the  customer. 

4.4  DATA  ACQUISITION 

The  basic  function  of  an  onboard  test  system  is  to  detect  and  isolate 
failures  in  the  aircraft  systems.  To  perform  this  function,  the  test  system 
must  acquire  the  necessary  subsystem  signal  parameters  required  to  conduct 
the  various  test  algorithms  for  each  system  tested.  The  major  sources  for 
these  signal  parameters  are:  operational  signals,  existing  LRU  test  para¬ 
meters,  individual  LRU  BIT  status,  and  added  test  interfaces  and  sensors. 
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The  test  system  must  interface  with  these  signal  sources,  which  may  be  analog, 
discrete,  or  serial  digital,  and  convert  these  signals  to  a  format  compatible 
for  transmission  to  the  test  system  data  processor(s) .  Test  system  hardware 
must  be  developed  to  access  each  test  parameter,  process  the  data,  and  provide 
the  test  results  to  the  flight  and  maintenance  crews.  Methods  for  performing 
these  functions  are  therefore  discussed  and  the  advantages  and  disadvantages 
of  each  method  is  provided. 

The  acquisition  of  test  data  can  be  costly  both  in  weight  and  dollars  if 
not  done  properly.  Past  experience  indicates  that  the  "at -the -source"  data 
acquisition  technique  satisifies  these  two  criteria  of  minimum  added  weight 
and  minimum  dollars  because  the  acquisition  unit  utilizes  common  conversion 
circuitry  which  is  shared  by  all  systems  under  test.  The  DAD  would  serve 
three  separate  but  related  functions:  1)  data  acquisition  of  monitored  para¬ 
meters  from  system,  2)  conversion  of  the  signals  to  data  bus  format  for  trans¬ 
mission  to  central  computer,  and  3)  an  isolation  device  which  enables  the  test 
system  hardware  or  software  failures  not  to  interfere  with  the  normal  operation 
of  the  system  under  test. 

4.4.1  SIGNAL  TYPES 

There  are  three  basic  signal  types  used  for  onboard  testing  purposes: 

1 .  Analog 

2.  Discrete 

3.  Serial  Digital 

4. 4. 1.1  Analog  Signals 

Analog  parameters  can  be  monitored  by  the  test  system  as: 

1.  Force 

2 .  Stress 

3.  Torque 

4.  Pressure 
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5.  Translational  Velocity 

6.  Strain 

7.  Temperature 

8.  Displacement 

9.  Flow  Rate 

10.  Angulai  Velocity 

The  above  parameters  can  be  monitored  as  voltages  by  means  of  electronic 
conversion  circuitry  situated  in  the  LRU's  of  the  system  under  test,  or  in 
the  DAD  of  the  onboard  test  system.  The  test  system  designer  must  analyze 
the  systems  he  is  testing,  both  off-the-shelf  and  new  designs,  in  order  to 
decide  what  voltage  ranges  are  most  prevelant  so  that  he  can  specify  these 
for  his  test  system  analog  interfaces.  These  parameter  ranges  most  likely 
would  be  one  or  more  of  the  following: 

1.  OV  to  +  10V 

2.  -10V  to  +  10V 

3.  OV  to  +  28V 

4.  OV  to  +  5V 

5.  -5V  to  +  5V 

The  designer  should  also  perform  a  trade  study  on  cost  incurred  when 
designing  for  any  of  the  voltage  ranges  he  is  considering  in  order  to  obtain 
the  most  cost  effective  design.  The  B-l  CITS  program  used  the  0-5V  range 
because  circuitry  costs  were  less  than  for  other  ranges  and  zero  to  five  volt 
scaling  circuitry  is  readily  available,  thus  keeping  development  costs  to  a 
minimum. 

When  utilizing  many  analog  signals  from  one  system  LR.U,  the  designer 
should  consider  a  serial  analog  interface  in  order  to  reduce  the  number  of 
input/output  circuits  necessary  to  acquire  the  system  data  for  testing  purposes. 
This  type  of  interface  would  involve  using  a  serial  digital  address  channel 
to  request  the  parameters  to  be  sampled,  one  at  a  time,  and  a  common  analog 
input  circuit  for  sampling  the  requested  signals.  The  one  problem  in  this 
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technique  is  the  time  required  to  sample  large  quantities  of  signals  when  com¬ 
parison  tests  are  being  utilized  in  the  test  logic.  The  data  samples  taken 
would  have  aged  enough  that  a  comparison  between  the  parameters  would  occasion¬ 
ally  result  in  a  false  indication  by  the  test  system. 

Another  area  of  concern  when  using  analog  signals  for  system  testing  is 
the  implementation  of  sample  and  hold  circuitry  in  the  DAD.  The  sample  and 
hold  function  enables  the  designer  to  effectively  have  a  multiparameter  simu¬ 
ltaneous  sampling  function.  The  following  are  examples  of  when  this  function 
can  be  used: 

1.  To  check  redundant  subsystems  by  measuring  the  same  test  point  in 
each  of  the  redundant  circuits  and  comparing  them. 

2.  In  the  area  of  engine  testing,  the  same  test  points  for  all  engines 
can  be  checked  against  each  other  for  comparison. 

4. 4. 1.2  Discretes 

4. 4. 1.2.1  Input  Discretes 

Input  discretes  can  represent  one  of  the  following  states: 

1.  Open  or  Closed 

2.  High  or  Low 

3.  In  or  Out 

4.  On  or  Off 

These  signals  can  be  provided  by  switch  closures,  proximity  switches, 
and  discrete  voltage  levels. 

Normally  a  voltage  discrete  signal  is  zero  volts  for  logic  zero  and  five 
volts  for  logic  one,  but  they  also  could  be: 

1.  OV  =  logic  0,  +  28V  =  logic  1 

2.  OV  =  logic  0,  +  10V  =  logic  1 
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The  designer  would  have  to  perform  studies  to  determine  which  is  the 
optimal  form  for  him  to  use  related  to  the  type  of  equipment  used  on  the 
aircraft . 

The  resultant  DAD  design  should  have  the  capability  of  accepting  both 
ON/OFF  voltage  discretes  and  switch  closures,  depending  on  the  neede  estab- 
listed  by  the  designer's  studies  of  the  number  and  type  of  discretes  needed 
for  testing  purposes. 

The  input  discretes  obtained  by  the  test  system  are  used  to  either  obtain 
failure  information  directly  or  establish  preconditions  for  a  test  on  a  system. 

4. 4. 1.2. 2  Output  Discretes 

When  the  contractor's  maintenance  concept  requires  verification  of  main¬ 
tenance  action  by  test,  additional  testing  capability  beyond  passive  system 
monitoring  is  necessary.  The  added  testing  capability  would  involve  stimula¬ 
ting  a  system,  on  the  ground  only,  by  means  of  discrete  signal  outputs  from 
the  test  system.  The  usage  of  these  type  of  output  discretes  would  be  to 
activate  those  circuits  which  would  not  be  active  during  normal  ground  oper¬ 
ations. 

l\hen  implementing  this  type  of  active  testing  in  such  systems  as  flight 
controls  or  avionics  where  either  aircraft  surface  movement  or  high  inten¬ 
sity  radio  transmission  is  possible,  certain  safety  precautions  have  to  be 
taken.  To  implement  such  a  test  the  designer,  working  with  the  safety  ana¬ 
lysts,  would  study  the  precautions  necessary  in  order  that:  1)  the  active 
test  can  never  occur  while  the  aircraft  is  in-flight  and  2)  the  ground  crew 
can  execute  the  test  safely.  To  solve  the  problem  of  safety  in  ground  testing 
the  B-l  CITS  personnal  developed  a  scheme  to  lock  out  testing  if  certain  pre¬ 
conditions  were  not  present  in  the  aircraft.  The  following  example  is  posed 
to  illustrate  how  this  function  is  executed  in  a  system. 


The  example  deals  with  the  B-l  aircraft  AICS.  This  system,  when  stim¬ 
ulated  by  CITS,  simulates  changes  in  aircraft  Mach  number  and,  via  the  AICS 
controller,  moves  the  variable  surfaces  of  the  inlet  duct  to  the  engine.  The 
movement  of  these  surfaces  is  very  hazardous  to  anyone  inside  the  duct,  near 
the  duct  sides,  or  near  the  front  opening.  To  insure  safety  of  this  test  a 
triple  software  and  triple  hardware  lockout  mechanism  was  developed.  The 
triple  software  lockout  was  comprised  of  the  CITS  establishing  three  conditions 
to  be  present  on  the  aircraft  before  the  output  discrete  could  be  used  to  the 
AICS  for  test  commencement.  The  three  conditions  were: 

1.  Landing  gear  squat  switch  closed  (aircraft  is  on  the  ground). 

2.  Parking  brake  on. 

3.  Stimulus  switch  on  CCD  manually  depressed  (closed) . 

The  triple  hardware  lockout  would  be  similar  but  would  be  implemented 
within  the  system  LRU  under  test  to  insure  redundancy  of  the  safety  lockout. 

A  significant  aspect  of  the  lockout  mechanism  is  the  stimulus  switch  on 
the  control/display  panel.  The  switch  enables  the  operator  to  have  the  option 
to  terminate  the  test  if  conditions  surrounding  the  aircraft  take  a  sudden 
change,  possibly  endangering  the  ground  crew. 

4. 4. 1.3  Serial  Digital 

The  serial  digital  interface  is  the  most  economical  of  all  the  input/out¬ 
put  circuits  when  many  signals  are  required  from  a  single  LRU.  The  capability 
of  being  able  to  transmit  many  signals  on  a  single  pair  of  wires  reduces 
weight  in  aircraft  wiring  and  the  amount  of  test  system  and  LRU  input/output 
circuitry. 

Anothe  .*  advantage  the  serial  digital  interface  has  is  in  the  area  of 
fixed  analog  values  and  accuracy  during  transmittal.  When  the  signal  orig¬ 
inates  as  an  analog  within  a  system  black  box  it  is  in  a  low  noise  environment. 
At  the  source  it  is  converted  to  a  digital  signal,  fixing  it  at  a  particular 
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value  and  accuracy.  The  fixed  value  is  then  transmitted  on  request  along  a 
pair  of  wires  to  the  DAD. 

For  new  system  designs,  the  designer  would  first  have  to  determine  how 
many  signals  are  required  from  a  single  LRU.  He  would  then  perform  a  study 
estimating  the  cost  and  weight  impact  of  hardwiring  all  of  the  signals  and 
implementing  a  serial  digital  interface  between  the  LRU  and  the  DAD.  When 
these  estimates  have  been  prepared  the  designer  would  weigh  than  against  the 
aircraft  design  constraints  and  decide  between  the  hardwired  or  serial  digital 
interfaces  for  implementation. 

4.4.2  SELECTION  GUIDELINES  FOR  DAD 

4.4. 2.1  Aircraft  Signal  location  Density 

Aircraft  signal  location  density  is  an  extremely  important  factor  in  the 
design  of  the  onboard  test  system  because  it  not  only  determines  where  and  how 
many  DAD's  are  necessary  for  the  onboard  test  system,  but  also  if  a  single  DAD 
design  is  feasible  for  all  locations  or  whether  the  design  will  require  dif¬ 
ferent  configurations  of  the  DAD's.  Examples  of  low  and  high  density  areas 
on  aircraft  are  listed  below: 

1.  High  signal  density  locations 

A.  Engines 

B.  Electrical  generators 

C.  Hydraulic  and  fuel  pumps 

D.  Engine  controls 

E .  Pneumat ic  cont  ro 1 s 

2.  Low  signal  density  locations 

A.  Cargo  and  weapons  bays 

B.  Qiter  wing  areas 
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The  low  and  high  density  areas  for  a  particular  aircraft  would  be  deter¬ 
mined  when  an  overview  of  the  aircraft  systems  is  prepared.  In  low  signal 
density  locations,  one  may  find  that  rerouting  signals  to  a  more  dense  area 
is  more  efficient  than  installing  a  DAD  in  tha*  area.  After  the  layouts  of 
system  installation  are  prepared,  preliminary  locations  for  DAD's  near  the 
high  density  centers  would  then  be  selected  for  design  studies  and  spares 
allocations.  The  test  designer  would  then  determine  the  quantity  and  type 
of  signals  for  each  LRU  located  in  each  equipment  location.  After  the  above 
step  is  completed,  the  total  number  of  each  type  of  signal  is  determined  in 
order  to  size  the  channel  requirements  for  a  given  DAD  location.  In  order 
to  utilize  a  common  DAD  design,  the  DAD  is  sized  for  the  quantity  of  each 
signal  type  for  the  most  dense  location  for  that  signal  type. 

Tradeoffs  relating  weight,  cost,  and  spares  can  then  be  made  to  deter¬ 
mine  if  more  than  one  DAD  in  a  location  would  be  more  effective  in  order  to 
maximize  the  used/ spare  channel  requirements. 

4. 4. 2. 2  Timing  of  Samples 

When  the  system  test  design  requirements  are  written,  analysis  of  the 
system  response  rate  determines  what  data  sampling  rate  is  required  for  test¬ 
ing.  In  order  to  utilize  a  serial  digital  interface,  all  data  obtained  for 
testing  purposes  must  be  converted  to  serial  digital  form  within  the  LRU  from 
which  the  interface  is  made. 

An  example  illustrating  some  of  the  restrictions  that  are  involved  in 
timing  of  data  samples  is  shown  in  the  following: 

As  an  example,  if  one  were  to  use  sixteen  samples  per  second  for  the  test 
rate,  the  analog  to  digital  converter  would  have  to  perform  to  a  certain  time 
span  for  conversion  of  the  analog  signals  in  order  to  complete  its  tasks  in 
time  for  the  test  to  be  performed  on  the  system.  For  this  example  assume  that 
100  analogs  have  to  be  converted  in  order  to  do  a  sixteen  times  per  second  test. 
Each  time  slot  would  have  62.5  milliseconds.  This  means  the  DAD  would  have 
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62.5  milliseconds  to  sample  and  digitize  100  analog  signals,  at  0.625  milli¬ 
seconds  per  signal.  Analog  to  digital  converters  range  from  conversion  times 
of  microseconds  to  milliseconds.  For  this  example  one  would  pick  a  conver¬ 
sion  time  of  less  than  0.625  milliseconds,  which  by  state-of-the-art  methods 
is  easily  met,  but  for  amounts  of  signals  in  the  thousands,  finding  A/D  con¬ 
verters  with  the  proper  speed  and  accuracy  is  more  difficult. 

4.4. 2. 3  Signal  Isolation  Requirements 

Another  important  factor  in  the  design  of  the  DAD  is  the  signal  isola¬ 
tion,  through  the  DAD,  from  the  system  under  test.  Depending  on  what  type 
of  interface  is  involved,  (discrete,  analog,  serial  digital)  the  isolation 
techniques  would  differ.  These  techniques  are  discussed  in  paragraph 
4. 7. 1.1. 2. 2. 

4. 4. 2. 4  Data  Acquisition  Accuracy 

When  acquiring  serial  digital,  discrete,  or  analog  data  from  a , system 
under  test,  it  is  important  to  specify  the  accuracy  of  the  test  parameters 
for  each  of  the  systems  under  test.  If  not  done,  testing  capability  would 
he  compromised,  due  to  signals  which  are  not  accurate  enough  to  detect  subtle 
changes  due  to  failures  in  the  systems  under  test.  When  making  decisions  on 
obtainable  signal  accuracies,  tradeoffs  which  have  to  be  made  involve  the 
accuracy  required  to  test  the  systems,  and  the  cost  of  implementation.  In 
onboard  test  systems,  the  test  results  are  as  accurate  as  the  signals  that 
are  used.  It  is  for  this  reason  that  the  DAD  hardware  designer  must  specify 
the  A/D  conversion,  analog,  serial  digital,  and  discrete  accuracies  that  sat¬ 
isfy  the  performance  requirements  of  the  test  system. 

4.5  DATA  RECORDING 

Onboard  recording  of  data  acquired  by  the  onboard  test  system  provides 
the  means  for  ground  analysis  of  airborne  malfunctions  which  cannot  be 
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duplicated  on  the  ground,  for  extremely  complex  malfunctions  beyond  the  scope 
of  the  onboard  test  system,  and  for  engine  and  primary  systems  trending  data 
during  flight  operations.  The  data  recording  capacity  must  be  sufficient  to 
provide  time  correlated  maintenance  data  for  failure  events,  for  evaluation 
of  subsystem  accuracies,  failure  prediction,  and  reliability  tracking  of  sub¬ 
system  performance. 

An  onboard  test  recording  capabilty  provides  the  system  designer  with  a 
means  of  increasing  the  efficiency  of  both  the  onboard  test  system  and  the 
aircraft  systems  during  the  development  cycle.  Data  recording  capacity  is 
a  function  of  failure  rate  predictions,  average  number  of  words  recorded  per 
failure,  average  mission  flight  times,  and  the  types  and  numbers  of  trending 
blocks  to  be  recorded.  There  are  several  types  of  recording  devices  and  re¬ 
lated  selection  guidelines  which  will  be  discussed  in  this  section. 

4.5.1  TYPES 

4. 5. 1.1  Analog 

Analog  recorders  are  usually  used  when  maximum  resolution  is  desired  to 
investigate  system  performance  characteristics.  These  types  of  devices  have 
multiple  channels,  recording  one  signal  per  channel.  Analog  recorders  are 
not  selective  in  what  times  are  recorded,  in  that  the  recorder  must  be  turned 
on  and  off  to  select  when  data  would  be  recorded.  In  addition,  when  the  re¬ 
corder  is  wired  for  specific  signals  to  be  recorded,  the  only  way  to  change 
signals  is  to  rewire  the  device. 

For  an  onboard  test  recording  application,  the  analog  method  is  not  prac¬ 
tical  because  of  the  limited  capability  to  record  many  signals  at  any  one 
time.  In  addition,  the  signals  recorded  are  fixed  and  difficult  to  change, 
because  of  the  hardwired  configuration. 
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4. 5. 1.2  Serial  Digital 

The  serial  digital  format  is  the  most  popular  and  practical  form  for 
recording  data  from  an  onboard  test  system.  This  method  enables  all  data 
to  be  recorded  on  a  four  wire  interface,  with  the  capability  of  changing 
what  is  recorded  via  the  software  program  in  the  test  system.  Serial  digital 
recorders  are  lighter  in  weight  than  the  analog  type  because  common  circuitry 
is  used  by  all  signals  incoming  from  the  test  system,  rather  than  having  a 
separate  channel  for  each. 

4.5.2  HARDWARE 

There  are  three  basic  types  of  data  recording  devices: 

1.  Disc  Drive 

2 .  Memory  Drum 

3.  Magnetic  Tape 

In  the  following  paragraphs  the  three  devices  are  discussed  with  respect 
to  their  advantages  and  disadvantages  as  recording  mechanisms  for  onboard 
test  applications. 

4. 5. 2.1  Disc  Drive 

4. 5. 2. 1.1  Advantages 

4. 5. 2. 1.1.1  Data  Access  Time.  In  the  areas  of  data  reduction  or  data  retriev¬ 
al,  this  device  excels  beyond  memory  drums  and  magnetic  tapes  because  the 
recording  head  has  immediate  access  to  the  entire  magnetic  recording  surface. 

4. 5. 2. 1.1. 2  Bit  Density.  The  disc  drive  has  the  capability  of  higher  bit 
densities  than  the  other  two  devices  considered  in  this  section. 
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4. 5. 2.1. 2  Disadvantages 

The  disc  drive  is  susceptible  to  vibration  because  the  flat  recording 
disc  spins  on  a  perfectly  balanced  shaft  at  very  high  speeds  and  the  record¬ 
ing  head  must  maintain  a  precise  air  gap  between  itself  and  the  recording 
surface.  Due  to  the  inherent  precision  required  for  proper  operation,  current 
designs  of  disc  drives  are  not  adequate  to  withstand  the  rapid  changes  in 
vibration  levels  which  are  inherent  in  aircraft  flight  conditions. 

4. 5. 2. 2  Memory  Drum 

The  memory  drum  device  provides  the  maximum  recording  capacity  of  the 
three  devices  conpared,  and  the  least  susceptible  to  data  loss  due  to  magnetic 
fields.  There  is  one  major  area  of  concern  and  that  is  the  mechanization  of 
recorded  data  extraction.  The  memory  drum  itself  is  not  removable  from  the 
device  enclosure  which  would  require  the  entire  recorder  to  be  removed  from 
the  aircraft  and  taken  to  the  data  processing  station  for  data  extraction. 
Utilization  of  this  type  of  recorder  would  increase  the  amount  of  spares  nec¬ 
essary  to  sustain  a  full-up  flight  ready  configuration. 

4. 5. 2. 3  Magnetic  Tape 

Today  all  aircraft  which  utilize  data  recording,  both  military  and 
commercial,  have  chosen  magnetic  tape  devices  for  their  application.  The 
magnetic  tape  data  recorder  has  the  following  advantages  and  disadvantages. 

4. 5. 2. 3.1  Advantages 

4. 5. 2. 3. 1.1  Airworthiness.  The  magnetic  recording  head  is  fixed,  whereas 
the  disc  drive  has  a  movable  head,  thus  enabling  proper  operation  in  a  vary¬ 
ing  environment. 
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4. 5. 2. 3. 1.2  Maintainabil ity .  The  hardware  involved  is  the  least  complex  of 
the  three  devices  compared. 

4. 5. 2. 3. 1.3  Reliability.  Hardware  simplicity  leads  to  high  reliability. 

4. 5. 2. 3.1.4  Cost.  The  probability  of  procuring  an  off-the-shelf  magnetic 
tape  recorder  is  high  compared  to  a  disc  drive  or  memory  drum  device. 

4. 5. 2. 3. 2  Disadvantages 

4. 5. 2. 3. 2.1  Access  Time.  This  is  due  to  the  inherent  operation  of  the  mag¬ 
netic  tape  recorder  in  that  to  access  a  piece  of  data  the  tape  has  to  wind  or 
unwind  to  that  point  in  the  tape. 

4.5.2. 3.2.2  Recording  Capacity.  The  available  magnetic  material  for  record¬ 
ing  on  a  tape  is  less  than  that  of  a  disc  or  memory  drum. 

4. 5. 2. 3. 2. 3  Bit  Density.  The  density  of  magnetic  material  on  the  tape  is 
less  than  the  other  two  devices  compared. 

4. 5. 2. 3. 2. 4  Impact  of  Disadvantages.  The  above  areas  of  concern  have  been 
overcome  with  high  efficiency  playback  devices  for  access  time  improvement , 
multirecording  tracks  and  special  recording  patterns  for  data  density  and 
capacity  capabilities. 

4.5.3  SELECTION  GUIDELINES  FOR  RECORDING  DEVICES 

When  selecting  a  recording  device  for  a  particular  onboard  test  system 
application,  the  following  factors  must  be  considered  before  a  selection  is 
made: 
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1.  Airworthiness  -  This  is  the  ability  of  the  recording  device  to  with¬ 
stand  the  environment  of  vibration,  temperature,  and  acoustic  noise 
in  which  it  must  operate. 

2.  Maintainability.  These  requirements  would  include  such  areas  as 
ground  crew  access,  ease  of  reloading,  and  ease  of  cleaning  record¬ 
ing  heads. 

3.  Accuracy.  This  pertains  to  the  ability  of  the  recorder  to  load  the 
data  onto  the  magnetic  surface  of  the  medium  implemented  with  min¬ 
imum  errors. 

4.  Reliability.  The  reliability  requirement ’ has  to  be  augmented  by 
the  mission  completion  reliability  in  order  to  establish  what  the 
recorder  should  perform  to. 

5.  Cost 

6.  Weight 

7.  Recording  Capacity.  See  paragraph  4. 5. 3.1. 

8.  Bit  Density.  This  is  a  factor  necessary  in  determining  how  much 
magnetic  surface  is  necessary  to  record  the  required  amount  of  data 
for  one  flight. 


4. 5. 3.1  Recording  Capacity  Required 

When  the  system  test  requirements  have  been  established,  including  all 
test  signals  and  sample  rates,  the  data  recording  device  can  be  sized  for  the 
task  of  recording  by  accounting  for  the  following  factors: 

1.  Number  of  failures  per  operating  hour  of  the  aircraft. 

2.  Number  of  total  aircraft  parameters  to  be  recorded  when  a 
failure  is  detected. 

3.  Frequency  of  non-failure  recordings  of  aircraft  parameters. 

4.  Engine  and  general  system  trending  data  points,  both  frequency 
and  quantity  of  signals. 


t 
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5. 


Number  of  crew  initiated  aircraft  data  recordings  per 
flight. 

6.  Maximum  flight  hours  for  a  mission. 

The  following  example  illustrates  what  calculations  are  necessary  to 
estimate  the  total  recording  capacity  required  for  an  onboard  testing  system. 
For  this  example  assume  the  following: 

Nj.  =  Number  of  failures/hour  =  2 

Np  =  Number  of  parameters  recorded/failure  =  1,000 

f  =  Frequency  of  non- failure  recordings/hour  =  2 

f  =  Frequency  of  engine  parameter  recordings/flight  =  5 

Ng  =  Number  of  engine  parameters  recorded  =  500 

Nc  =  Number  of  crew  initiated  recordings  =  5 

t  =  Maximum  flight  hours  =24 


Total  recording  capacity  = 


CNf)  (Np)  (t)  +  (f  )  (Np)  (t)  +  (fe)  (Ne)  +  (Nc)  (N  ) 

(2)  (1,000)  (24)  +  (2)  (1,000)  (24)  +  (5)  (500)  + 

(5)  (1,000) 

48,000  +  48,000  +  2,500  +  5,000 


=  105,500  16  bit  words  of  data 


=  105,500  words  x  16  bits/word 
=  1.69  mega  bits 

For  the  above  example  test  system  a  recorder  with  a  minimum  recording 
capacity  of  1.69  mega  bits  would  be  required. 


4.6  HARDCOPY  PRINTERS 

The  purpose  of  the  hardcopy  printer  is  to  print  the  results  of  the  on¬ 
board  test  for  quick- look  data  to  be  used  by  the  ground  crew  immediately  upon 
the  landing  of  the  aircraft. 
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4.6.1  PRINTER  FEATURES 


4. 6. 1.1  Printer  Heads 

4. 6. 1.1.1  Thermal 

The  thermal  printer  head  prints  by  means  of  heating,  in  dot  patterns, 
special  paper  in  order  to  record  the  test  result  information.  This  technique 
is  limited  to  room  temperature  or  cooler  environmental  conditions.  Extreme 
heat  conditions  would  tum  the  special  paper  to  a  purple  color  and  would  be 
unusable  for  printing  purposes. 

4 . 6 . 1 . 1 . 2  Inpact 

This  printing  technique  involves  the  characters  being  printed  by  inpact 
either  on  special  no-carbon  paper  or  by  means  of  an  ink  ribbon.  If  the  rib¬ 
bon  were  not  used  special  paper  coated  with  encapsulated  ink  modules  would 
be  used.  When  struck  these  capsules  break  and  the  ink  would  spread  to  the 
paper  forming  the  struck  characters.  This  special  paper  is  restricted  to 
room  temperature  or  above  because  at  cold  temperature  the  ink  will  not  flow, 
thus  when  struck  no  inprint  is  made. 

4. 6. 1.1. 3  Vaporization 

This  method  involves  a  spark  discharge,  in  dot  patterns  of  the  characters, 
to  vaporize  the  zinc  oxide  coating,  of  specially  coated  paper,  down  to  the 
black  colored  background.  The  special  printer  paper  will  work  for  a  wide 
temperature  range  and  has  a  long  shelf  storage  life  with  minimal  degradation. 
This  particular  technique  was  used  for  the  B-l  CITS  system  because  of  its 
wide  operating  temperature  range. 

4.6. 1.2  Paper  Feed  Mechanization 
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4. 6. 1.2.1  Strip 

This  style  of  paper  is  similar  to  ticker  tape.  The  paper  is  approxi¬ 
mately  a  half  inch  wide  and  would  be  fed  through  the  printer  via  a  reel -to - 
reel  mechanism.  The  strip  style  paper  feed  mechanism  was  implemented  on  the 
B-l  CITS  because  of  two  main  reasons:  1)  the  printer  unit  was  essentially 
off  the  shelf  and  2)  it  met  all  the  operating  environment  requirements. 

4. 6. 1.2. 2  Roll 

This  technique  poses  a  problem  when  utilized  in  an  aircraft  in  that  when 
the  paper  is  printed  on  and  is  being  unrolled,  the  gathering  and  storing  of 
the  used  paper  is  difficult. 

4. 6. 1.2. 3  Page 

This  technique  would  utilize  a  mechanism  which  would  feed  a  stack  of 
perforated  pages  through  the  printing  head.  Storage  of  the  unused  and  used 
paper  would  be  a  problem  for  aircraft  applications. 

4.6.2  SELECTION  GUIDELINES  FOR  HARDCOPY  PRINTERS 

The  following  represents  those  factors  to  consider  when  selecting  a  hard¬ 
copy  printer  for  onboard  test  applications. 

4.6. 2.1  Printing  Speed 

This  factor  is  related  to  the  amount  of  information  to  be  printed.  The 
designer  would  have  to  estimate  how  much  will  be  printed  and  evaluate  the 
printer  on  the  basis  of  speed  of  output. 

4. 6. 2. 2  Character  Set 

The  system  test  requirements  would  dictate  what  characters  are  needed 
for  output  of  test  results.  The  designer  would  evaluate  the  printer  on  the 
basis  of  capability  of  printing  all  of  the  different  characters  needed. 
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4. 6. 2. 3  Environmental  Suitability 

The  main  evaluation  the  designer  must  make  is  to  determine  if  the  chosen 
printer  can  meet  the  environmental  requirements.  The  two  major  concerns  are 
operating  temperature  range  and  vibration.  The  criteria  established  for  en¬ 
vironmental  conditions  concerns  the  printer  outputting  legible  characters 
throughout  the  temperature  and  vibration  ranges. 

4. 6. 2. 4  Weight 

The  controlling  factor  in  weight  of  the  total  printer  device  is  dependent 
on  the  type  of  printer  head  chosen,  because  of  the  electromechanical  complex¬ 
ities  inherent  in  each  one.  The  impact  type  head  is  the  heaviest  of  the  three 
because  of  its  mechanical  complexity,  whereas  the  vaporization  type  head  has 
the  lightest  impact  to  weight. 

4.6. 2. 5  Reliability 

The  reliability  of  the  printer  is  mainly  due  to  the  paper  feed  mechanism 
complexity,  therefore  the  least  complexity  would  produce  the  lightest  reliabi¬ 
lity. 

4. 7  INTERFACES 

The  performance  of  testing  systems  onboard  an  aircraft  is  dependent  on 
proper  connection  of  the  test  system  and  its  interfaces.  These  interfaces 
include  data  signals  (serial  digital,  analog,  and  discrete),  power,  and  cool¬ 
ing.  The  following  will  discuss  serial  digital,  analog,  and  discrete  signal 
interfaces;  sensor  types  and  selection  guidelines;  noise  and  methods  of  fil¬ 
tration;  signal  accuracy  and  repeatability;  power;  and  cooling. 

4.7.1  DATA  SIGNALS 

Data  signals  are  the  source  of  system  performance  information  needed  by 
the  onboard  test  system  to  perform  the  fault  detection/isolation  testing.  The 
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following  will  discuss  aspects  which  the  designer  would  focus  his  attention 
on  in  order  that  an  optimum  design  can  be  developed. 

4. 7.1.1  Signal  Types 

4. 7. 1.1.1  Serial  Digital 

There  are  three  main  format  types  for  serial  digital  data: 

1 .  Manchester 

2.  Bipolar  Return  to  Zero 

3.  Bipolar  Non-Return  to  Zero 

4. 7. 1.1. 1.1  Manchester.  Manchester  code  is  a  bi-phase  level  non-retum  to 
zero  type  format.  The  bi -phase  level  interpretation  of  the  zero,  one  bit 
pattern  is  described  as  follows: 

Level  changes  occur  at  the  center  of  every  bit  time 
period,  by  which  a  "one"  is  represented  by  a  "one" 
level  with  a  transition  to  the  "zero"  level,  and  a 
"zero"  is  represented  by  a  "zero"  level  with  a  tran¬ 
sition  to  the  "one"  level.  An  illustration  of  this 
format  is  given  in  Figure  4-3. 

4. 7. 1.1. 1.1.1  Advantages.  The  following  paragraphs  list  the  advantages  of 
implementing  this  data  format. 

4. 7. 1.1. 1.1. 1.1  Ease  of  Transmission  -  Capable  of  transmitting  on  long  lengths 
of  communication  lines  because  of  the  automatic  redundancy  characteristics  of 
the  signal. 


4. 7. 1.1. 1.1. 1.2  Redundancy  -  Redundancy  is  inherent  because  the  Manchester 
bit  information  is  created  by  the  signal  transition  about  the  zero  volt  line, 
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Bipolar  Retum-to-Zero  (RZ) 


Serial  Digital  Signal  Format  Types 
Figure  4-3 
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and  is  not  solely  dependent  upon  the  magnitude  of  the  peaks  of  the  square 
waveforms. 


4. 7. 1.1. 1.1. 1.3  Readability  -  Redundancy  characteristic  enables  the  equip¬ 
ment  to  read  the  Manchester  format  even  if  half  of  the  waveform  is  lost. 

4. 7. 1.1. 1.1. 1.4  Noise  Sensitivity  -  This  format  enables  the  signal  to  be 
inherently  insensitive  to  surrounding  electrical  noise. 

4. 7. 1.1. 1.1. 1.5  Synchronization  -  Manchester  is  self  clocking  which  elim¬ 
inates  the  need  for  a  synchronization  signal  in  the  receiver.  Circuit  syn¬ 
chronization  signals  are  used  to  enable  both  transmitter  and  receiver  to  be 
in  time  with  each  other  with  respect  to  starting  and  stopping  message  trans¬ 
mission. 

4. 7. 1.1. 1.1. 2  Disadvantages.  The  following  paragraphs  list  the  disadvan¬ 
tages  of  using  Manchester  coded  serial  digital  signals. 

4. 7. 1.1. 1.1. 2.1  Implementation  Cost  -  This  format  incurs  the  highest  cost 
of  implementation  of  the  three  formats  discussed  in  this  section. 

4. 7. 1.1. 1.2  Bipolar  Return  to  Zero.  The  Bipolar  Return  to  Zero  (RZ)  coded 
signal,  as  shown  in  Figure  4-3,  is  shaped  such  that  the  last  half  of  the  bit 
information  width  is  always  at  a  zero  volt  level.  The  receiving  circuit  rec¬ 
ognizes  the  bit  information  as  a  delta,  either  plus  or  minus,  from  the  zero 
volt  line. 

4. 7. 1.1. 1.2.1  Advantages.  This  format  has  the  lowest  cost  of  implementation 
of  the  three  formats  discussed  in  this  section. 
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4. 7. 1.1. 1.2. 2  Disadvantages. 


4. 7. 1.1. 1.2. 2.1  Noise  Sensitivity  -  The  noise  sensitivity  is  higher  because 
of  the  method  of  detection  of  a  logic  one  or  zero,  which  is  dependent  on  the 
signal  voltage  levels  in  the  RZ  waveform. 

4. 7. 1.1. 1.2. 2. 2  Ease  of  Transmission  -  Due  to  the  sensitivity  to  voltage  lev¬ 
els  for  logic  interpretation,  the  transmission  line  length  is  limited  to  cur¬ 
tail  excessive  capacitance,  impedance,  and  noise  reception. 

4. 7. 1.1. 1.3  Bipolar  Non-Retum-to-Zero.  The  third  digital  format  that  can 
be  utilized  is  Bipolar-Non-Retum-to-Zero  (NRZ) ,  as  shown  in  Figure  4-3. 

4. 7. 1.1. 1.3.1  Advantages.  This  format  will  withstand  long  lengths  of  trans¬ 
mission  lines  without  distortion  to  the  signal  shape. 

4. 7. 1.1. 1.3. 2  Disadvantages.  This  type  of  format  has  a  higher  sensitivity 
to  electrical  noise.  The  noise  sensitivity  is  affected  by  the  logic  zero  and 
logic  one  detection  method. 

4. 7. 1.1. 1.4  Selection  Rationale  for  B-l  Aircraft.  The  B-l  CITS  utilized  two 
of  the  previously  discussed  signal  formats  -  Manchester  and  RZ.  The  Manchester 
signal  format  was  selected  for  the  communication  data  bus  link  between  the  CITS 
dedicated  computer  and  the  CITS  peripherals  because  of  the  length  requirement 
of  the  data  bus  on  the  aircraft,  accuracy,  interface  protocol,  and  noise  rejec¬ 
tion  characteristics. 

The  RZ  data  format  was  selected  to  interface  between  the  CITS  DAU's  and 
the  aircraft  systems  under  test  because  the  length  of  the  data  links  were 
less  than  twenty-five  feet,  the  cost  of  the  interface  hardware  was  low,  the 
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availability  of  the  hardware  was  off-the-shelf,  and  the  higher  error  rate  (due 
to  electrical  noise)  was  manageable  with  the  CITS  three-pass  software  filter 
on  detected  failures. 

The  B-l  CITS  was  designed  prior  to  the  development  of  the  MIL -STD-1553 
specification.  For  future  design  applications  for  the  B-l  CITS,  MIL-STD-1553 
version  of  the  Manchester  data  bus  architecture  is  recommended  to  replace  the 
B-l  Manchester  data  bus  because  MIL-STD-1553  input/output  hardware  is  avail¬ 
able  as  off-the-shelf  technology/hardware  whereas  the  B-l  Manchester  input/ 
output  hardware  is  custom  designed.  For  interfacing  with  aircraft  systems, 
it  is  still  recommended  that  the  lower  cost  RZ  interface  design  be  retained. 

4. 7. 1.1. 1.5  Serial  Digital  Design  Requirements. 

4. 7. 1.1. 1.5.1  Timing.  The  timing  requirements  are  dependent  on  how  much  data 
is  anticipated  for  monitoring  and  how  many  tests  have  to  be  performed  during 

a  one  second  period.  An  example  of  this  timing  requirement  can  be  seen  in 
Appendix  C,  Figure  8.  This  example  is  taken  from  B-l  CITS  system  Bipolar  RZ 
(Self -Clocking)  Serial  Digital  Output/Input  Signal.  It  can  be  seen  that  the 
pulse  width  for  logic  zero  and  logic  one,  and  dead  time  widths  are  critical 
to  proper  signal  interpretation  by  the  receiver  circuitry.  Another  example 
of  timing  can  also  be  seen  in  Appendix  C,  paragraph  3. 2. 1.3,  Data  Rate.  The 
Standard  Signal  Interface  Specification  requires  that  the  serial  digital  sig¬ 
nals  be  transmitted  at  a  one  megabit  rate  plus  or  minus  0.1  percent.  This 
timing  requirement  is  congruent  to  the  timing  requirements  of  the  pulse  widths 
shown  in  Appendix  C,  Figure  8.  The  one  megabit  rate  is  based  on  the  required 
amount  of  data  related  to  how  many  tests  are  to  be  executed  and  the  time  period 
that  all  tests  have  to  be  completed  for  a  one  second  time  slot. 

4. 7. 1.1. 1.5. 2  Signal  Magnitude.  When  one  is  considering  magnitude  require¬ 
ments  both  input  and  output  characteristics  have  to  be  designed  separately. 
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In  Appendix  C,  paragraph  3. 2. 4. 4. 5.1,  the  output  voltage  requirements  are 
shown  to  be  five  plus  or  minus  one  volt  for  logic  "1"  and  minus  five  plus 
or  minus  one  volt  for  logic  "0".  The  input  circuit  should  be  able  to  accept 
a  wide  range  of  voltages  in  order  to  account  for  noise  effects,  signal  ring¬ 
ing,  mismatched  impedances,  and  improper  wire  types.  The  input  circuit  sig¬ 
nals  magnitude  requirements  can  be  seen  in  Appendix  C,  paragraph  3. 2. 4. 4. 5. 2. 
Logic  "1"  is  shown  to  be  plus  two  and  one-half  to  six  volts  and  logic  "0"  is 
shown  to  be  minus  two  and  one-half  to  minus  six  volts.  These  voltage  ranges 
were  widened  to  accommodate  discrepancies,  already  discussed,  and  enable  more 
acceptance  to  serial  digital  data  without  malfunctioning.  These  examples  are 
developed  from  experience  gained  from  the  B-l  CITS  program. 

4. 7. 1.1. 1.5. 3  Signal  Shape.  The  idealized  signal  shape  of  serial  digital 
data  is  a  square  waveform.  The  actual  shape  of  the  waveform  seen  in  the  hard¬ 
ware  is  generally  a  square  configuration,  but  the  peaks  are  somewhat  rounded 
off.  This  rounding-off  effect  is  defined  by  the  rise  and  fall  times  of  the 
digital  circuitry  producing  the  waveform.  The  excessive  rise  and  fall  times 
are  caused  by  excessive  capacitance,  inductance,  and  impedance  mismatches. 

When  procuring  such  circuitry,  requirements  for  rise  and  fall  times  must  be 
defined  so  the  hardware  designers  know  that  restrictions  are  levied  on  the 
resultant  serial  digital  interface  design.  An  example  of  this  type  of  re¬ 
requirement  can  be  seen  in  Appendix  C,  paragraph  3. 2. 4. 4. 5.1. 

4. 7. 1.1. 1.5. 4  Data  Bus  Architecture.  The  data  bus  architecture  is  deter¬ 
mined  by: 

4. 7. 1.1. 1.5. 4.1  Data  Bus  Impedance  -  Choosing  the  proper  wire  type  for  con¬ 
struction  of  the  test  system  data  bus  is  important  because  if  the  impedance 
is  not  correct  it  would  cause  attenuation  of  the  magnitude  of  the  serial  digital 
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pulse -modulated  signal  such  that  it  could  be  vulnerable  to  electrical  noise 
(i.e.,  ringing).  An  example  of  a  reconmended  data  bus  wire  type  is  one  that 
was  used  on  the  B-l  CITS  system.  The  wire  was  teflon  coated  twisted  shielded 
pair  and  had  a  72  ohm  impedance  at  one  kilohertz,  with  a  capacitance  of  20 
picofarads  per  foot,  and  wire  size  of  24  gauge.  This  wire  type  is  recommend¬ 
ed  because  it  will  match  the  interface  requirements  set  by  the  data  acquisi¬ 
tion  device  recommended  guidelines  and  will  result  in  an  almost  lossless  line 
effect. 


4. 7. 1.1. 1.5. 4. 2  Data  Bus  Termination  Devices  -  There  are  two  devices  which 
are  used  for  termination  of  serial  digital  interfaces.  The  devices  used  are 
transformers  and  operational  amplifiers.  The  transformer  interface  is  used 
on  the  transmitter  side  because  of  low  impedance  and  capability  of  driving 

a  longer  transmission  line.  The  serial  digital  signal  is  a  harmonic  made  up 
of  frequencies  ranging  from  250  kilohertz  to  five  megahertz.  The  transformer 
interface  has  to  be  designed  to  transmit  the  entire  range  of  frequencies. 

The  other  type  of  serial  digital  interface  used  is  an  operational  amplifier 
specially  designed  for  serial  digital  interfaces.  This  special  type  of  oper¬ 
ational  amplifier  is  used  in  the  receiver  circuit  because  of  its  high  input 
impedance.  It  is  always  important  when  transmitting  signals  down  a  line  to 
go  from  a  low  impedance  to  a  high  impedance  to  minimize  reflections  on  the 
line  which  would  affect  the  transmitted  waveform  shape. 

4. 7. 1.1. 1.5. 4. 3  Selection  of  Data  Bus  Format  -  When  selecting  the  data  bus 
format  to  be  used  for  a  particular  application,  the  following  characteristics 
should  be  considered: 

A.  Accuracy 

B.  Electrical  Noise  Sensitivity 

C.  Length  of  Transmission  Lines 

D.  Clocking 
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E.  Cost  of  Implementation 

F.  Reliability 

G.  Compatibility  With  Off-the-Shelf  Hardware 

H.  Interface  Protocol  Complexity 

I .  Hardware  Complexity 

Table  IV- 1  illustrates  a  trade  study  the  designer  would  have  to  perform 
in  order  to  select  the  proper  data  bus  format  for  his  particular  application. 

4. 7. 1.1. 1.5. 5  Isolation.  As  in  interface  devices,  the  transformer  and  opera¬ 
tional  amplifier  also  serve  as  very  efficient  isolation  devices  when  building 
serial  digital  interfaces.  The  function  of  an  isolation  device  is  such  that 
when  a  failure,  open  or  short,  exists  in  the  onboard  test  system,  the  failure 
is  not  propagated  into  the  system  under  test.  The  transformer  is  excellent 
in  this  respect  because  of  its  isolation  winding  structure.  The  operational 
anplifier  with  its  special  dxode  arrangement  enables  only  one  way  direction 
of  signal  transmission. 

4. 7. 1.1. 2  Analog 

An  analog  signal  is  an  electrical  representative  of  a  physical  or  elec¬ 
trical  phenomenon  relating  characteristics  information  from  an  event  in  time. 
The  onboard  test  system  utilizes  many  of  these  type  signals.  However,  they 
must  be  converted  to  a  digital  form  in  order  that  computational  or  logical 
functions  can  be  performed.  The  following  describes  the  analog  to  digital 
process  and  electrical  isolation  required  for  the  onboard  test  system. 

4. 7. 1.1. 2.1  Conversion  Process.  When  converting  analog  signals  into  dig¬ 
ital  signals,  a  tradeoff  study  involving  factors  such  as  bit  word  length, 
accuracy,  repeatability,  and  conversion  time,  is  required  before  the  final 
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HARDWARE  COMPLEXITY 


process  can  be  chosen.  Analog  signals  are  converted  into  different  bit  word 
lengths  depending  on  accuracy  and  resolution  requirements.  There  are  three 
main  techniques  available  to  accomplish  this  conversion. 

The  designer  selecting  the  conversion  technique  must  perform  an  analysis 
and  evaluate  not  only  speed  and  accuracy,  but  also  hardware  availability,  cost, 
weight,  internal  circuit  requirements  for  the  data  acquisition  device,  and 
number  of  analog  signals  to  be  converted. 

4. 7. 1.1. 2. 1.1  Successive  Approximation.  This  process  entails  the  circuitry 
to  perform  the  following  steps: 

A.  The  circuitry  counts,  in  a  digital  register,  a  value  of  one-half  of 
full  scale. 

B.  The  value  is  converted  to  an  analog  and  compared  to  the  input  analog. 

C.  If  the  input  analog  is  greater  than  the  counted  value,  the  second 
most  significant  bit  is  turned  on  producing  a  three  quarters  full 
scale  value,  if  the  input  signal  is  less  than  the  counted  value, 
the  second  and  third  most  significant  bits  are  turned  off  and  the 
fourth  most  significant  bit  is  turned  on  producing  a  value  five 
eighths  of  full  scale. 

The  above  procedure  is  continued  until  the  final  value  is  obtained  which 
compares  to  the  input  analog  signal  within  the  accuracy  limits.  The  advantages 
and  disadvantages  of  this  procedure  are: 

A.  Advantages 

1.  The  A/D  conversion  is  very  fast. 

2.  Reasonable  accuracy  is  acquired. 

3.  Good  repeatability. 

B.  Disadvantages 

1.  The  cost  of  implementation  is  higher  than  the  integration  and 
counter  types. 
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4. 7. 1.1. 2. 1.2  Integration  Type.  An  example  of  the  integration  type  technique 
is  the  Dual  Slope  Method.  This  method  requires  that  a  capacitor  be  charged 
for  a  fixed  time  period  gaining  change  to  a  predetermined  value.  At  the  end 
of  the  time  period  the  circuitry  switches  to  a  negative  reference  voltage  un¬ 
til  the  comparator  in  the  circuit  has  reached  its  threshold.  The  final  con¬ 
verted  value  is  the  ratio  of  the  counts  cf  the  negative  charge  time  period  to 
the  positive  charge  time  period. 

The  advantages  and  disadvantage  of  implementing  this  technique  are: 

A.  Advantages 

1.  Low  cost  of  implementation. 

2.  High  resolution. 

B.  Disadvantage 

1.  Slow  conversion  time  due  to  the  inherent  charge  time  of  the 
capacitor. 

4. 7. 1.1. 2. 1.3  Counter.  The  counter  method  involves  a  counter  to  start  count¬ 
ing  from  zero  and  converted  to  an  analog  value  compared  to  the  input  analog. 
When  the  desired  accuracy  is  obtained  the  count  is  terminated  leaving  the 
desired  A/D  conversion  value  ready  to  be  utilized  by  the  test  system.  The 
conversion  time  is  dependent  on  both  the  bit  word  length  and  the  magnitude 

of  the  analog  value  to  be  converted. 

The  advantages  and  disadvantage  of  this  technique  are: 

A.  Advantages 

1.  Least  complex  of  the  three  techniques  discussed. 

2.  Lowest  cost  of  implementation. 

B.  Disadvantage 

1.  Slowest  conversion  time. 
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4. 7. 1.1. 2. 2  Isolation  Schemes.  After  the  designer  has  chosen  the  analog  con¬ 
version  process,  an  electrical  isolation  technique  must  be  selected.  The  de¬ 
signer  should  perform  an  analysis  to  choose  between  two  feasible  approaches. 

4. 7. 1.1. 2. 2.1  Operational  Amplifier.  This  method  would  use  an  operational 
amplifier  with  a  resistor  matrix  for  fixed  gain  and  short-circuit  protection. 
This  technique  is  used  when  the  system  is  being  designed  around  new  hardware 
where  signal  characteristics  and  interfaces  have  not  been  established.  This 
type  of  isolation  scheme  has  been  used  successfully  on  the  B-l  aircraft  for 
the  CITS  system. 

4. 7. 1.1. 2. 2. 2  Programmable  Gain  Amplifier.  This  type  of  amplifier  is  suitable 
for  designs  which  involve  off-the-shelf  hardware  which  would  have  various  inter 
face  requirements  and  voltage  ranges.  With  this  type  of  circuitry  the  computer 
would  control  the  gain  of  the  amplifier  to  matcl  the  unique  interfaces. 

An  example  of  this  can  be  seen  in  the  B-l  aircraft.  In  the  B-l  most  of 
the  interface  equipment  was  designed  for  the  special  applications  of  the  CITS 
system  where  interfacing  analogs  were  zero  to  five  volts  or  minus  five  to  plus 
five  volts.  Therefore,  the  isolation  circuitry  situated  in  the  BAU  or  in  the 
system  under  test  would  be  a  commonly  used  design  of  an  operational  amplifier 
with  fixed  gain  and  short-circuit  protection.  This  application  would  not  be 
true  in  smaller  aircraft  where  generally  analogs  vary  from  zero  to  twenty-eight 
volts  and  the  hardware  is  off-the-shelf  which  mandates  all  isolation  circuitry 
to  be  within  the  DAU.  This  case  would  lend  itself  to  the  programmable  gain 
amplifier.  Many  different  voltage  range  signals  could  be  multiplexed  through 
the  same  amplifier  and  the  program  could  vary  the  gain  for  that  particular 
signal  at  any  one  time  of  sampling.  During  the  trade  study  period  the  designer 
must  decide  where  the  flexibility  is  going  to  be  so  that  he  can  specify  the 
proper  hardware  to  perform  efficient  analog  signal  isolation. 


V 
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4. 7. 1.1. 3  Discrete 

A  discrete  signal  represents  a  unique  event  in  a  manner  of  translating 
information  in  the  form  of  an  "on"  or  "off"  state.  The  following  describes 
the  processing  of  these  type  of  signals  and  the  isolation  techniques  needed 
to  satisfy  those  electrical  interface  requirements  for  the  onboard  test  system. 

4. 7. 1.1. 3.1  Processing/Isolation  Schemes.  When  processing  discrete  input 
signals  one  has  to  keep  in  mind  that  they  are  small  in  magnitude  and  are 
sensitive  to  noise  from  other  high  power  sources.  These  effects  can  be  min¬ 
imized  when  proper  interface  and  isolation  circuitry  is  used.  Three  exanples 
of  isolation  interfaces  are  provided  for  design  consideration. 

4. 7. 1.1. 3. 1.1  Resistor.  The  designer  can  consider  using  a  simple  circuit  of 
a  10K  ohm  resistor  connected  in  series  with  a  multiplex  circuit  and  then  to 

a  register  which  would  contain  the  discrete  piece  of  information. 

A.  Advantages 

1.  Simple. 

2.  Inexpensive. 

B.  Disadvantage 

1.  This  circuit  does  not  provide  adequate  isolation  capability 
in  exessive  noise  environments. 

4. 7. 1.1. 3. 1.2  Differential  Amplifier.  The  designer  would  increase  the  iso¬ 
lation  capability  of  the  above  technique  by  adding  a  differential  amplifier 
between  the  resistor  and  the  multiplexer. 

A.  Advantages 

1.  Enables  common  mode  rejection. 

2.  Eliminates  cyclic  noise. 

B.  Disadvantage 

1.  This  technique  will  not  filter  out  electromagnetic  pulses  (EMP) . 
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4. 7. 1.1. 3. 1.3  Optical  Isolator.  If  the  designer  wishes  to  eliminate  EMP 
effects,  he  would  replace  the  differential  amplifier  from  technique  number 
two  and  replace  it  with  an  optical  isolator. 

A.  Advantages 

1.  The  optical  isolator  is  an  off-the-shelf  item. 

2.  Relatively  inexpensive  and  available  to  the  user. 

3.  Reduces  ground  looping  effects. 

Another  consideration  when  processing  discretes  is  whether  the  data  is 
parallel  or  serial.  The  preceding  techniques  apply  only  to  parallel  data. 

When  considering  serial  discrete  data  a  flip-flop  circuit  has  to  be  used  in 
series  with  a  ten  thousand  ohm  resistor  and  registers  for  storage  of  the 
serial  discrete  information.  In  addition  to  this  circuit  the  other  circuits 
can  be  used  for  minimization  of  noise. 

4. 7.1.2  Sensors 

When  performing  the  onboard  test  function,  system  parameter  information 
is  necessary  to  enable  the  test  system  to  evaluate  the  aircraft  systems  under 
test.  Sensors  are  used  to  acquire  this  information.  Sensors  are  devices  that 
convert  electromechanical  phenomena  into  electrical  signals  which  are  sent  to 
the  test  system  for  processing  and  testing.  There  are  several  types  of  sensors 
and  guidelines  for  selecting  them  to  satisfy  the  testing  requirements.  These 
factors  will  be  discussed  in  the  following  paragraphs. 

4. 7. 1.2.1  Types 

The  two  basic  types  of  sensors  are  analog  and  discrete.  The  analog  type 
sensor  is  used  to  access  and  measure  voltages,  currents,  frequencies,  angular 
position,  linear  position,  pneumatic  pressure,  fluid  pressure,  rotation,  and 
speed.  The  following  defines  these  types  and  their  individual  attributes. 


4. 7. 1.2. 1.1  Linear  Variable  Differential  Transformer  (LVPT) .  These  sensors 
relate  linear  position  and  motion.  An  example  of  an  application  of  this  type 
of  sensor  can  be  seen  in  a  jet  engine.  This  sensor  can  be  used  to  measure 
actuator  stroke  on  a  variable  nozzle  configuration.  The  accuracy  of  LVDT 
sensors  usually  run  from  approximately  three  to  five  percent.  After  cond- 
tioning,  scaling,  and  digitizing  the  resulting  electrical  signal,  the  accu¬ 
racy  would  be  from  four  to  five  percent.  The  reliability/ repeatability  of 
this  type  sensor  is  good,  even  in  adverse  environments. 

4. 7. 1.2. 1.2  Rotary  Variable  Differential  Transformer  (RVDT) .  This  sensor 
measures  angular  displacement.  A  typical  application  of  this  type  of  sensor 
is  in  the  determination  of  the  amount  a  valve  has  opened.  RVDT  signals  ''an 
be  used  to  calculate  characteristics  such  as  valve  opening  cross  sectional 
area  and  the  projected  flow  rate  through  the  valve.  The  accuracy  and  repeat¬ 
ability  is  comparable  to  the  characteristics  described  for  the  LVDT  device. 

4. 7. 1.2. 1.3  Pressure  Transducers.  Pressure  transducers  are  used  to  measure 
pneumatic  and  fluid  pressures.  There  are  two  basic  types  of  pressure  trans¬ 
ducers: 

A.  A  resistive  element  with  a  mechanical  wiper  to  generate  the  electr- 
cal  signal. 

B.  The  strain  gauge  type  of  pressure  sensor  with  no  moving  parts. 

In  most  cases  pressure  measurements  involve  a  very  small  delta  around  a 
fixed  pressure  reading.  Proper  application  of  the  two  types  of  sensors  is 
very  important.  In  the  B-l  aircraft  the  hydraulic  system  runs  normally  at 
four  thousand  pounds  per  square  inch  of  pressure  except  when  an  engine  start 
is  attempted.  In  the  pressure  measurement  system  a  resistive  type  of  sensor 
was  used.  This  type  proved  to  be  a  poor  choice  because  the  hydraulic  pressure 
varied  slightly  around  the  normal  pressure  most  of  the  time  and  the  constant 
friction  of  the  wiper  would  wear  in  one  spot  on  the  resistive  element.  This 
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wear  caused  noise  pulses  in  the  output  signal  when  any  vibration  was  applied 
to  the  sensor.  This  problem  can  be  cured  by  utilizing  the  second  type  (strain 
gauge)  pressure  sensors  because  of  their  solid  state  characteristics  where  sen¬ 
sor  degradation  is  minimized.  On  the  B-l  an  intermediate  fix  was  implemented 
by  means  of  adding  notch  filters  to  the  pressure  signal  conditioning  and  dis¬ 
tribution  unit.  This  minimized  the  vibration  effects  on  the  pressure  signals. 

4. 7. 1.2. 1.4  Acceleration  and  Vibration  Strain  Gauges.  Another  application  of 
the  strain  gauge  type  sensor  is  the  measurement  of  acceleration  and  vibration. 
Strain  gauge  sensors  are  accurate  devices  because  of  their  solid  state  nature 
and  the  fact  that  measurements  are  determined  from  small  variations  from  a  fix¬ 
ed  reference.  These  variations  can  be  electronically  converted  to  an  accel¬ 
eration  or  vibration  depending  on  the  particular  application. 

4. 7. 1.2. 1.5  Accelerometers .  In  addition  to  strain  gauges  for  the  measurement 
of  acceleration  and  vibration,  there  are  accelerometers.  These  devices  are  in¬ 
ductive  in  nature  when  a  coil  and  magnet  are  utilized  to  generate  a  cyclic  sig¬ 
nal  related  to  the  sensed  acceleration  or  vibration. 

4. 7. 1.2. 1.6  Synchros  and  Resolvers.  These  type  of  sensors  relate  position  of 
an  actuator  or  surface  which  may  be  involved  in  either  an  open  or  closed  loop 
control  system.  Examples  of  these  type  of  systems  can  be  seen  in  the  B-l  air¬ 
craft.  The  engine  thrust  control  system  utilizes  outputs  from  synchros  to 
determine  engine  throttle  position.  Another  example  of  this  type  of  sensing 
is  the  B-l  aircraft  flight  control  system  where  synchro  signals  are  used  for 
testing  system  health. 

4. 7. 1.2. 1.7  Temperature  Sensors. 

A.  Thermocouples  -  These  are  used  in  a  wide  variety  of  applications. 
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There  are  four  types  of  thermocouples: 

1.  Iron  -  constantan 

2.  Chrome 1  -  alimel 

3.  Platinum  -  rhodium 

4.  Copper  -  constantan 

The  chromel-alumel  type  is  most  commonly  used  because  of  low  cost, 
high  reliability,  and  wide  temperature  range. 

B.  Thermistors  -  These  devices  are  used  when  space  and  weight  are  lim¬ 
ited.  They  are  very  small  and  light  weight,  but  have  narrow  tem¬ 
perature  ranges. 

C.  Pyrometers  -  Pyrometers  are  optical  devices  which  sense  temperature 
radiation  through  a  lens  which  has  to  be  cleaned  periodically  for 
proper  measurement  accuracy.  These  devices  are  relatively  new  in 
design  and  have  seen  application  in  sensing  turbine  blade  temperature 
in  jet  engines.  (These  devices  operate  in  a  high  temperature  envi¬ 
ronment  starting  at  about  seven  hundred  degrees  centigrade.  Their 
accuracy,  including  signal  processing  ranges,  is  approximately  plus 
or  minus  twenty  degrees  centigrade. 

4. 7. 1.2. 1.8  Voltage  Dividers.  The  voltage  divider  is  used  to  monitor  voltages. 
This  method  of  monitoring  prevents  high  voltage  wires  from  being  spread  excess¬ 
ively  throughout  the  aircraft.  High  voltage  wires  are  always  a  source  of  elec¬ 
trical  noise.  The  usual  way  the  voltage  dividers  are  implemented  are  with  re¬ 
sistors  forming  a  bridge  circuit.  The  accuracy  and  reliability  is  dependent 
upon  the  accuracy  and  reliability  of  the  resistors  used. 

4. 7. 1.2. 1.9  Current  Transformers.  Current  transformers  are  used  to  measure 
electrical  currents  and  loads.  These  devices  perform  a  dual  task:  Voltage/ 
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current  divider,  and  2)  Electrical  isolation  from  the  system  under  test. 
Current  transformers  vary  in  size  and  weight  depending  on  voltage,  current, 
and  frequency.  The  reliability  of  these  devices  is  high  due  to  their  solid 
state  characteristics.  The  one  disadvantage  with  a  transformer  device  when 
measuring  current  is  the  effect  temperature  has  on  accuracy  of  measurement. 

As  the  temperature  varies,  the  resistance  of  the  windings  change,  thus  chang¬ 
ing  the  current  ratios.  The  designer  should  take  care  when  utilizing  this  de¬ 
vice  that  the  environmental  temperature  is  relatively  constant  such  that  curr¬ 
ent  changes  can  only  be  attributed  to  the  system  under  test  and  not  resistance 
changes  in  the  coils. 

4.7.1.2.1.10  Tachometers.  These  devices  are  used  to  detect  speed  of  rotating 
parts  with  high  accuracy  and  reliability.  The  accuracy  of  this  device  with 
digital  processing  can  be  as  accurate  as  three-tenths  of  one  percent.  Appli¬ 
cations  of  this  device  can  be  seen  in  the  measurement  of  fan  speeds  on  jet 
engines,  pump  rotation  speed  in  hydraulic  systems,  and  gear  train  speeds  in 
auxiliary  power  units. 

4.7.1.2.1.11  Quantity  Probes.  Propulsion  systems,  fuel  systems,  and  hydrau¬ 
lic  systems  are  typical  examples  where  fluid  quantity  measurement  are  required 
for  testing.  This  is  accomplished  by  using  quantity  probes.  Quantity  probes 
consist  of  capacitive  elements  connected  in  parallel.  The  fluid  level,  as  it 
rises  and  falls,  changes  the  overall  capacitance  of  the  device.  The  monitor¬ 
ing  electronics  converts  these  capacitance  changes  into  voltage  changes  for 
testing  and  cockpit  display  purposes.  In  aircraft  applications  where  there 
there  are  varying  accelerations  affecting  gravity  pulls  on  the  fluid  and  dif¬ 
ferent  flight  attitudes  affecting  the  level,  great  care  has  to  be  taken  to 
preclude  reading  the  fluid  level  without  taking  into  account  these  factors 
which  would  give  erroneous  flight  quantity  levels.  An  example  of  an  erroneous 
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reading  can  be  seen  in  the  B-l  aircraft  CITS  engine  test.  At  the  beginning 
of  the  flight  test  program  there  were  false  indications  of  lube  quantity. 
Analysis  indicated  that  every  time  the  aircraft  was  exposed  to  negative  ver¬ 
tical  acceleration  the  oil  would  float  to  the  top  of  the  lube  tank  above  the 
quantity  probe  indicating  low  lube  level.  This  problem  was  cured  by  adding 
a  precondition  to  the  lube  quantity  test  of  checking  for  positive  vertical 
acceleration.  The  accuracy  of  this  device  is  dependent  on  how  many  capacitive 
elements  there  are.  Past  experience  has  shown  this  device  to  be  a  very  reli¬ 
able  unit  with  good  repeatability. 

4.7.1.2.1.12  Inductive  Coil.  This  sensor  is  used  for  monitoring  rotation 
and  frequency  whenever  reliability  and  durability  are  a  requirement.  These 
devices  are  excellent  for  harsh  environments  of  temperature  and  vibration. 

4.7.1.2.1.13  Discrete  Sensors.  These  devices  are  used  to  detect  events  such 
as  on,  off,  set  points,  limits,  open,  and  closed  positions.  There  are  dis¬ 
advantages  in  using  discrete  sensors.  When  using  these  sensors  for  set  points 
and  limits  for  monitoring,  values  chosen  are  factory  set  and  therefore  dif¬ 
ficult  to  change.  An  example  of  this  problem  can  be  seen  in  the  B-l  CITS 
fuel  system  test.  The  fuel  transfer  pumps  of  the  B-l  have  discrete  pressure 
sensors  incorporated  to  indicate  proper  operation  of  the  punps.  The  hardware 
limits  selected  for  change  of  state  of  the  discrete  were  improper  and  many 
erroneous  indications  occurred.  If  an  analog  sensor  were  used  then  a  software 
limit  could  easily  be  changed  to  correct  the  limit  selection.  The  open  and 
closed  position  application  has  its  drawbacks  also.  When  a  valve  is  monitored 
with  a  discrete  sensor,  the  test  system  never  knows  whether  the  valve  opens  or 
closes  to  the  proper  position,  only  that  the  valve  is  open  or  closed.  The 
reason  this  type  of  device  is  used  in  lieu  of  an  analog  device  is  because  of 
weight  and  test  system  logic  simplicity.  Discrete  devices  are  light  weight 
and  small  in  size  whereas  analog  devices  are  heavier  and  more  complex  and 


•»v 


4-52 


require  additional  scaling  and  isolation  circuitry  before  enabling  acquisition 
by  the  test  system. 

4. 7. 1.2.2  Selection  Guidelines 

There  are  two  classes  of  sensors  utilized  on  an  aircraft  equipped  with  an 
onboard  test  system:  1)  aircraft  systems  function  (operational)  sensors  and 
2)  onboard  test  system  dedicated  sensors.  When  determining  the  type  of  opera¬ 
tional  and  dedicated  sensors  required  to  perform  the  onboard  test  of  an  air¬ 
craft  system/LRU  to  meet  both  the  operational  requirements  and  the  maintenance 
requirements,  trade  studies  must  be  performed  on  each  subsystem/LRU  by  both 
the  system  designer  and  the  test  system  designer  in  order  to  meet  both  require¬ 
ments  effectively.  The  study  would  provide  a  base  of  operational  sensors, 
which  would  be  augmented  with  dedicated  test  sensors  where  needed  to  meet  the 
fault  detection/isolation  requirements  of  the  test  system.  When  selecting  the 
additional  test  sensors,  priority  should  be  given  to  existing  test  interfaces 
over  adding  new  sensors  for  the  express  purpose  of  testing.  In  lieu  of  adding 
sensors  it  may  be  desirable  to  use  deductive  test  techniques  utilizing  existing 
sensors  rather  than  adding  new  unique  ones.  The  resultant  set  of  sensors,  both 
operational  and  dedicated,  would  be  integrated  into  the  onboard  test  system 
design. 

The  following  represents  those  aspects  which  the  designer  must  consider 
when  selecting  sensors  for  his  onboard  test  system  design: 

4. 7. 1.2. 2.1  Range  of  Measurement.  This  is  important  because  if  chosen  im¬ 
properly  the  range  of  interest  could  result  in  a  small  voltage  range  such  that 
electrical  noise  on  the  transmission  line  could  mask  the  information  needed 
for  the  signal. 

4. 7. 1.2. 2. 2  Sensitivity.  This  factor  is  the  ratio  of  output  to  unit  input 
and  is  important  for  fulfilling  system  resolution  requirements.  When  selecting 
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sensors  to  monitor  this  factor  for  closed  or  open  loop  control  systems  great 
care  must  be  taken  in  the  selection  process.  Inproper  sensor  selection  can 
lead  to  acquiring  signals  that  do  not  have  the  same  or  greater  response  time 
than  the  system  under  test,  thus  resulting  in  an  ineffective  parameter. 

4. 7. 1.2. 2. 3  Loading  Effects.  Sensors  should  be  chosen  such  that  loading 
effects  and  distortion  are  minimal  so  that  there  is  negligible  effect  on  the 
measured  or  monitored  sources. 

4. 7. 1.2. 2.4  Sensor  Frequency  Response.  The  sensor  should  have  a  frequency 
response  equal  or  greater  than  the  response  of  the  monitored  source.  If  the 
sensor  has  a  lesser  frequency  response,  subtle  changes  in  system  operaton  that 
were  faster  than  the  response  time  of  the  sensor  would  be  missed.  This  con¬ 
dition  would  cause  a  damping  effect  on  the  resultant  signal,  which  in  some 
cases  may  be  favorable. 

4. 7. 1.2. 2. 5  Physical  Installation  of  Sensor.  The  designer  must  always  place 
sensors  in  an  optimum  location  in  order  to  promote  ease  of  replacement  when 
failed. 

4. 7. 1.2. 2. 6  Working  Environment.  The  sensor  must  be  tolerant  of  its  working 
environment.  Environment  factors  such  as  humidity,  vibration,  temperature, 
shock,  electromagnetic  fields,  radiation,  and  contamination  should  be  considered. 
An  example  of  how  these  factors  affect  sensor  selection  and  placement  can  be 
cited  from  the  B-l  engine  design:  A  sensor  was  needed  to  relate  nozzle  pres¬ 
sure,  but  if  a  sensor  were  to  be  added  in  that  particular  area  of  the  engine 

it  would  melt  due  to  the  extreme  temperatures  of  the  exhaust  gases.  A  study 
was  done  and  it  was  found  that  a  cooler  area  in  the  front  of  the  engine  had 
a  pressure  which  was  equal  to  the  nozzle  pressure  and  could  house  a  sensor 
properly.  A  sensor  was  then  selected  and  installed  and  has  given  very  reliable 
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and  accurate  pressure  readings  throughout  the  flight  test  program. 


4. 7. 1.2. 2. 7  Output  Electrical  Format  and  Impedance  Compatibility.  The  elec¬ 
trical  format  and  impedance  of  the  sensor  chosen  must  be  compatible  with  the 
test  system  in  terms  of  event  detection  and  sensitivity. 

4. 7. 1.2. 2. 8  Reliability.  Sensors  should  be  selected  that  are  reliable.  If 
a  sensor  has  to  be  installed  into  a  relatively  inaccessible  area  in  the  air¬ 
craft,  the  most  reliable  sensor  available  should  be  utilized.  This  will  de¬ 
crease  maintenance  problems  when  the  aircraft  is  in  the  field. 

4. 7. 1.2. 2. 9  Accuracy.  This  factor  is  always  one  of  the  main  factors  in  the 
selection  of  proper  sensors  for  the  task  of  testing  a  system.  The  accuracy 
of  test  results  is  dependent  on  the  accuracy  of  the  signals  used.  Inaccurate 
sensors  can  result  in  detected  faults  which  would  fall  in  the  gray  area  of 
indecision  whether  a  maintenance  action  is  necessary  or  not. 

4. 7. 1.3  Problem  Areas 

There  are  three  main  problem  areas  when  testing  systems  in  real-time: 

1)  Electrical  noise,  2)  Signal  accuracy  and  repeatability,  and  3)  Reliability 
of  conditioning  and  isolation  devices.  The  following  will  discuss  the  causes 
of  these  problems  and  what  can  be  done  to  enable  the  test  system  designer  to 
minimize  these  from  his  initial  design. 

4. 7. 1.3.1  Electrical  Noise 

Electrical  noise  is  a  series  of  electrical  inpulses  which  transmit  through 
air  and  can  be  received  on  electrical  cables  which  carry  signals  containing  vi¬ 
tal  test  information  from  operational  systems.  The  result  of  noise  is  a  signal 
which  is  not  compatible  to  the  test  system.  The  direct  result  which  affects  the 
test  system  is  the  false  indications  it  causes.  The  following  discusses  some 


4-55 


sources  and  possible  ways  to  reducing  the  effects  to  the  test  system's  outputs. 


4. 7. 1.3. 1.1  Sources.  The  following  describes  the  two  main  sources  of  elec¬ 
trical  noise: 

4. 7. 1.3. 1.1.1  High  Power  Lines.  Tne  major  source  of  electrical  noise  is  high 
power  lines.  The  noise  results  in  a  sinusoidal  waveform,  normally  at  a  fre¬ 
quency  of  four  hundred  hertz  or  sixty  hertz,  being  added  to  another  test  sig¬ 
nal  resulting  in  a  new  waveform  which  the  test  system  would  interpret  as  a 
system  failure. 

4. 7. 1.3. 1.1. 2  Multiplexing  Systems.  Another  source  of  noise,  which  has  come 
about  since  the  advent  of  electrical  multiplexing  systems,  is  a  multitude  of 
electrical  blips  caused  by  chattering  relays,  circuit  breakers,  and  solid 
state  logic  circuitry.  These  sources  cannot  be  eliminated  because  their  ex¬ 
istence  as  systems  on  an  aircraft  is  essential  to  flight  of  the  vehicle,  but 
there  are  methods  of  reducing  their  effect  on  the  neighboring  systems. 

4. 7. 1.3. 1.2  Method  of  Eliminating/Reducing  Noise  Effects.  There  are  two 
basic  methods  of  reducing  the  effects  of  electrical  noise  on  producing  false 
indications  by  the  test  system;  1)  Filters  (hardware  and  software) ,  and  2) 
Proper  setting  of  failure  limits. 

4. 7. 1.3. 1.2.1  Filters 

4. 7. 1.3. 1.2. 1.1  Hardware  -  There  are  three  basic  types  of  hardware  filters: 

4. 7. 1.3. 1.2. 1.1.1  Inductive  Filter  -  The  most  popular  usage  of  the  inductive 
filter  is  the  smoothing  of  full  waveform  signals.  This  filter  is  most  effec¬ 
tive  at  higher  frequencies.  The  resultant  waveform  is  very  smooth  with  slight 
peaks  and  valleys. 
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4. 7. 1.3. 1.2. 1.1. 2  Capacitive  Filter  -  This  type  of  er  circuit  has  its 
highest  efficiency  at  lower  frequencies.  This  method  l  popular  for  noise 
problems  because  it  filters  out  those  frequency  ranges  most  associated  with 
high  power  lines. 

4. 7. 1.3. 1.2. 1.1. 3  L-Section  -  This  type  of  filter  is  made  up  of  both  in¬ 
ductive  and  capacitive  elements.  The  inductive  element  has  a  high  impedance 
for  the  harmonic  terms  in  the  voltage  portion  of  the  signal.  The  ripple  pro¬ 
duced  is  very  low  compared  to  the  ripples  produced  by  the  individual  inductive 
and  capacitive  filter  circuits.  Multiples  of  these  L-section  circuits  reduce 
the  ripple  even  further  and  would  be  used  when  a  very  smooth  signal  is  nec¬ 
essary  for  proper  test  results. 

4. 7. 1.3. 1.2. 1.2  Software  -  When  electrical  noise  affects  test  signals  the 
variations  which  occur  appear  to  be  periodic  in  nature.  The  net  effect  is 
test  signals  which  model  an  intermittent  failure.  Usually  these  interferences 
only  occur  for  very  short  periods  of  time.  The  signal  changes  cause  false  indi¬ 
cations  to  be  annunciated  by  the  test  system.  Most  of  these  types  of  problems 
can  be  filtered  out  by  software  means.  There  are  two  classes  of  software  fil¬ 
tering  that  can  be  utilized  by  the  test  system  designer  to  overcome  this  con¬ 
dition. 


4. 7. 1.3. 1.2. 1.2.1  Input  Signal  Filtering  -  This  technique  involves  inputting 
multiple  samples  of  each  test  signal  and  averaging  the  halves  for  the  test 
program. 


4. 7. 1.3. 1.2. 1.2. 2  Fault  Indication  Filtering  -  To  implement  this  type  of  soft¬ 
ware  filter,  programming  would  have  to  be  added  to  enforce  a  requirement  that 
before  a  failure  is  annunciated  it  has  to  exist  for  more  than  "n"  sample  times 
for  that  subsystem  under  test.  To  implement  this  kind  of  software  filter  across- 
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the-board  for  all  subsystems  may  not  be  practical.  Each  system  tested  must 
be  analyzed  for  their  unique  cases  to  determine  what  the  "n"  number  of  sample 
times  would  be. 

4. 7. 1.3. 1.2. 2  Proper  Setting  of  Failure  Limits.  Another  method  of  elimi- 
ating/ reducing  false  indications  due  to  signal  noise  is  to  properly  set  fail¬ 
ure  limits.  Past  experience  has  shown  that  most  failure  limits  are  set  too 
close  and  do  not  take  into  account  signal  accuracy,  signal  conditioning  accu¬ 
racy,  signal  acquisition  accuracy,  and  computer  accuracy.  In  addition  to  those 
elements  the  designer  should  take  into  account  the  accuracy  effects  caused  by 
electrical  noise.  It  is  recommended  that  for  systems  testing,  the  systems 
analyst  should  set  the  failure  limits  fairly  broad  in  order  to  see,  during 

the  flight  test  portion  of  the  program,  exactly  what  the  total  inaccuracies 
are  and  prevent  many  false  indications  from  being  annunicated  in  the  beginning 
of  the  program.  When  data  has  been  acquired  from  flight  test  these  limits  can 
be  tightened  to  the  actual  operating  line  of  the  system  under  test. 

4. 7. 1.3. 2  Signal  Accuracy/Repeatability 

Signal  accuracy  and  repeatability  are  two  important  factors  to  consider 
when  designing  an  onboard  test  system.  The  test  algorithms  used  for  the  test 
system  can  only  test  the  system  as  accurately  as  the  signals  it  uses.  Repeat¬ 
ability  of  a  signal  is  also  important  for  the  proper  identification  of  a  fail¬ 
ure  in  a  system.  Repeatability  is  that  characteristic  by  which  a  signal  will 
always  output  the  same  value  given  the  same  environmental  and  internal  con¬ 
ditions.  This  characteristic  is  important  because  when  the  test  algorithms 
are  designed  and  programmed  they  do  not  change.  The  basic  assumption  made 
when  using  fixed  logic  is  that  for  any  one  particular  failure  there  will  always 
exist  the  same  signal  pattern.  Therefore,  if  the  signals  were  not  repeatable, 
every  time  the  same  failure  occurred  different  signal  patterns  would  occur  and 
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one  set  of  logic  would  not  pick  up  that  failure  every  time.  In  addition,  to 
insure  proper  and  uniform  mechanization  requirements  the  designer  should  ex¬ 
ecute  a  trade  study  to  determine  what  the  minimum  requirement  for  accuracy  and 
repeatability  should  be  and  incorporate  this  into  each  aircraft  subsystem  pro¬ 
curement  specification. 

4. 7. 1.3. 3  Reliability  of  Conditioning/Isolation  Devices 

The  signals  which  are  acquisitioned  by  the  onboard  test  system  are  con¬ 
ditioned  and  isolated  from  the  sensor  prior  to  being  inputted  to  the  DAU.  If 
any  one  of  the  elements  in  the  chain  should  fail,  the  entire  signal  would  be 
lost.  This  means  the  conditioning  and  isolation  devices  would  require  the 
same  reliability  standards  that  the  sensor  would  have.  One  problem  associated 
with  this  type  of  circuitry  is  that  it  usually  resides  with  the  system's  LRU. 

In  seme  cases  during  an  aircraft's  flight  test  program  there  is  a  tendency  not 
to  replace  an  LRU  if  the  signal  failed  is  a  dedicated  onboard  test  parameter, 
and  the  LRU  is  still  operating  properly.  This  results  in  a  nuisance  fault 
indication  to  the  crews.  To  reduce  the  effects  of  these  human  tendencies  the 
designer  should  perform  a  trade  study  to  determine:  1)  What  is  the  highest 
reliability  of  conditioning  and  isolation  circuitry  available  within  cost  re¬ 
straints  and  2)  What  is  the  cost  tradeoff  of  attaining  higher  reliability  by 
implementing  redundancy  in  this  area.  Another  factor  to  consider  is  the  sim¬ 
plicity  of  the  circuitry  used.  If  the  result  of  the  trade  study  is  to  maintain 
non- redundancy,  the  designer  should  analyze  simplicity  with  respect  to  reli¬ 
ability  and  cost  to  obtain  the  most  optimun  design  to  assure  the  minimum  number 
of  failures. 

4.7.2  POWER 

All  electronic  equipment  require  power  supplies  for  their  operation.  The 
electronic  components  internal  to  the  onboard  test  system  are  made  up  of  com¬ 
puter  memories,  digital  registers,  A/D  and  D/A  converters,  and  linear  analog 
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amplifiers.  These  devices  require  very  low  current,  thus  resulting  in  low 
current  demands  for  the  entire  test  system.  The  power  supplies  for  test 
system  applications  would  have  the  following  three  critical  areas  of  concern: 

4. 7.2.1  Output  Voltage  Regulation 

This  is  critical  to  total  system  operation.  Digital  circuits  are  very 
sensitive  to  any  fluctuations  in  source  power,  thus  resulting  in  many  false 
indications  and  if  left  unchecked  would  cause  extensive  damage  to  the  circuits 
themselves.  From  past  experience,  to  maintain  digital  devices  in  good  working 
order,  a  voltage  regulation  of  less  than  one  percent  should  be  used.  This  will 
insure  that  the  powered  devices  are  not  operating  at  an  under  or  over  voltage. 

4. 7.2.2  Power  Supply  Package  Design 

This  factor  is  important  because  if  not  done  properly  high  temperature 
areas  (hot  spots)  can  occur.  Hot  spots  in  the  power  supply  are  very  real 
problems  and  special  attention  should  be  focused  on  these  during  the  initial 
design  effort.  These  hot  spots  usually  occur  around  high  power  transistors, 
output  voltage  regulators,  and  power  transformers.  Heat  problems  normally 
arise  from  improper  heat  sinking,  of  the  three  types  of  devices  previously 
mentioned,  and  when  high  temperature  items  are  placed  too  close  to  one  another. 
When  hot  parts  are  too  close  to  each  other  the  temperature  build-up  is  accel¬ 
erated,  therefore,  high  and  low  temperature  parts  should  be  intermingled  evenly 
on  the  circuit  board  to  distribute  the  temperature  more  evenly. 

4. 7. 2. 3  Short-Circuit  Protection 

Short  circuits  across  the  power  supply  not  only  can  damage  the  power  supply, 
but  can  cause  current  surges  to  be  inputted  to  the  circuitry  of  the  test  system. 
These  current  surges  will  cause  severe  damage  or  possible  electrical  fires  in 
the  exposed  circuitry.  The  power  supply  must  have  short-circuit  protection  in 
order  that  these  high  currents  will  not  persist. 
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4.7.3  COOLING 


The  basic  need  for  cooling  in  electrical  equipment  is  to  extract  excess 
heat  generated  in  the  equipment.  To  determine  the  cooling  requirements  for 
any  piece  of  electrical  equipment  a  thorough  thermal  analysis  must  be  performed. 
The  analysis  would  include  heat  dissipation  efficiency  of  heat  sinks  and  total 
LRU  enclosure  environment,  total  heat  generated  by  heat  generating  parts,  and 
total  heat  generated  by  the  entire  LRU.  All  of  these  factors  would  be  con¬ 
sidered  in  the  determination  of  what  temperature  cooling  air  is  needed,  what 
air  flow  rate  is  required,  and  where  it  should  be  inputted  and  exited  from  the 
LRU.  The  designer  is  alerted  to  the  fact  that  if  the  thermal  analysis  and 
cooling  configuration  design  are  not  performed  properly,  the  LRU  may  have 
overheating  problems  when  operating  in  the  aircraft. 

4.8  SUNrtARY 

The  design  of  onboard  test  system  hardware  involves  not  only  compliance 
with  weapon  system  onboard  test  requirements  but  also  consideration  of  cost, 
weight,  space,  reliability,  maintainability,  schedule,  power,  cooling,  air  crew 
interface,  and  systems-under-test  interface.  The  basic  function  of  the  test 
system  hardware  is  test  data  acquisition,  data  processing,  and  display  of  the 
status  of  the  systems-under-test.  Selection  guidelines  are  given  for  these 
hardware  functions  as  well  as  additional  functions  such  as  data  recording  and 
hardcopy  printing. 
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Section  5 


SOFTWARE  REQUIREMENTS  ANALYSIS 

5.1  ONBOARD  TEST  SYSTEM  SOFTWARE  DEVELOPMENT 

5.1.1  GENERAL  ELEMENTS  OF  SOFTWARE  DEVELOPMENT  PLAN 

According  to  Air  Force  Regulation  (AFR)  800-14,  all  computer  programs, 
including  onboard  test  systems  and  real-time  programs,  must  be  planned,  de¬ 
signed  and  tested  in  accordance  with  a  Computer  Program  Development  Plan 
(CPDPj .  The  elements  of  this  plan  should  include  provisions  for  objective 
definitions,  tasks,  breakdown  organization,  resources,  standards,  and  con¬ 
figuration  control.  The  CPDP  should  be  prepared  only  after  trade  studies, 
life  cycle  studies  and  risk  analysis  have  been  completed.  The  following  de¬ 
scribes  the  major  phases  convered  by  the  CPDP: 

a)  Analysis  Phase  -  During  this  phase,  the  functional  performance  re¬ 
quirements  for  the  computer  program  are  defined.  Included  also  is 
the  definition  of  the  functional  interface  and  possible  design  con¬ 
straints.  This  phase  usually  begins  with  the  release  of  system  spec¬ 
ifications  and  ends  with  a  PDR. 

b)  Design  Phase  -  In  this  phase,  a  program  design  including  functional 
and  detail  flow  charts  is  developed  and  subsequently  presented  to 
Critical  Design  Review  (CDR)  in  the  form  of  a  preliminary  product 
specification. 

c)  Coding  and  Checkout  Phase  -  Following  completion  of  CHI,  coding  and 
checkout  begin.  This  phase  usually  consists  of  the  "unit  testing" 
of  individual  program  modules  and  involves  a  combination  of  software 
simulation  and  laboratory  testing  and  may  be  considered  complete 
when  the  correct  outputs  are  generated  when  using  predefined  inputs. 
This  leads  into  the  integration  phase. 

d)  Test  and  Integration  Phase  -  During  this  phase,  the  Computer  Program 
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is  tested  against  the  requirements  contained  in  the  Computer  Program 
Development  Specification.  The  testing  may  extend  through  formal 
qualification  testing. 

e)  Installation  Phase  -  This  phase  includes  loading  and  running  of  the 
computer  program,  in  this  case  on  the  aircraft,  and  includes  total 
operability  and  compatibility  testing. 

f)  Operation  and  Support  -  This  phase  includes  making  updates,  cor¬ 
rections  and  deletions  and  requires  retesting.  New  programs  would 
require  reiteration  of  all  the  above  phases. 

5. 1.1.1  Software  Requirements 

Software  requirements  are  generated  during  the  analysis  phase,  as  pre¬ 
viously  described,  and  is  one  of  the  most  critical  aspects  of  the  software 
development.  Unless  a  complete,  unambiguous  and  feasible  set  of  requirements 
are  produced,  difficulties  may  arise  in  subsequent  phases.  Systems  engineering 
studies,  in  support  of  producing  the  requirements,  should  be  conducted  to  define 
interface,  performance,  design,  "man  in  the  loop"  considerations,  quality  assur¬ 
ance  and  safety.  It  may  also  be  necessary  to  develop  functional  simulations  to 
define  inputs,  outputs,  and  logic  for  each  functional  requirement.  At  the  com¬ 
pletion  of  this  effort,  the  program  should  be  temporarily  fixed  in  configuration, 
establishing  a  baseline  for  future  changes,  and  reflected  in  a  software  design 
specification. 

5. 1.1. 2  Software  Design 

The  organization  and  development  of  software  for  an  onboard  test  system 
should  be  made  immediately  visible  to  both  upper  management  and  the  customer 
at  the  start  of  the  program.  Top-down  development  and  requirement  traceability 
concepts  should  be  laid  out  early  for  review.  This  requires  the  coordination 
and  participation  of  software  designers  and  system  designers  through  the  require¬ 
ments  definition,  program  design,  implementation,  integration,  and  test  and 
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validation  phases.  Structured  top-down  design  is  recommended  as  a  basic  ap¬ 
proach.  This  implies  that  the  top  level  functions  can  be  allocated  to  programs 
and  subprograms  in  a  highly  modular  fashion  (see  Figure  5-1).  The  software  ar¬ 
chitecture  of  the  onboard  test  program  is  a  key  element  for  early  review.  This 
includes  communication  and  structuring  of  program  modules.  The  time  sequencing 
(execution  timir  of  these  program  modules  in  a  meaningful  time  line  (as  well 
as  executive  techniques  to  communicate  within  the  time  line)  is  important  to 
assess  adequacy  of  software  design.  Descriptions  of  data  flow  and  data  based 
architecture  to  support  the  program  modules  must  be  reviewed  in  depth. 

The  concept  of  shared  resources  such  as  shared  programs,  tables,  and  input/ 
output  data  must  be  analyzed  for  ease  of  development  and  maintenance.  All  of 
the  above  must  be  done  at  a  systems  engineering  level  in  order  to  assure  that 
proper  tradeoffs  have  been  made  in  the  overall  design.  This  evaluation  tests 
the  architecture  for  modularity,  flexibility,  modification  capability,  commu- 
nicativity,  and  preliminary  timing  and  is  the  top  subject  for  review  early  in 
the  program  and  throughout  the  program. 

5. 1.1. 2.1  Top-Down  Design 

Based  on  experience  with  CITS  it  is  recommended  that  the  design  of  onboard 
test  system,  real-time  computer  programs,  be  developed  using  hierarchical  pro¬ 
cesses  which  may  be  represented  by  design  trees.  Design  trees  represent  the 
software  architecture.  They  clearly  show  the  relationship  between  the  indi¬ 
vidual  modules  and  the  controlling  hierarchy.  An  example  of  a  design  tree  is 
given  in  Figure  5-2.  Preferably  no  more  than  three  levels  of  software  modules 
should  be  represented  per  tree.  The  activation  sequence  is  top  to  bottom,  left 
to  right.  Therefore,  referring  to  Figure  5-2,  RTE  activates  RETCON,  MDDER, 
PITCH,  YAW,  ROLL,  INNER,  AND  RACKG  in  sequence.  The  double  arrow  depicts 
activate  and  return.  The  "feet"  shown  at  the  lowest  level  shows  that  the 
tree  continues  in  subsequent  pages.  Nodes  in  design  trees  reflect  design  mod¬ 
ules  and  show  program  modularity.  High  level  modules  in  the  tree  should  be 
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designed  before  subordinate  low-level  modules. 


5. 1.1. 2. 2  Modular  Concept 

It  is  also  recommended  that  the  design  of  onboard  test  system  real-time 
software  be  modular  in  structure  as  previously  discussed.  The  software  should 
be  organized  to  allow  grouping  based  on  function,  timing,  and  memory  usage. 

The  fundamental  goal  of  such  a  modular  design  is  to  achieve  functional  inde¬ 
pendence  of  modules.  Every  design  module  should  be  implemented  as  a  separate 
and  identifiable  computer  program.  All  modules  should  have  a  single  entry 
and  exit  point,  if  possible.  Control  and/or  data  should  be  completely  spec¬ 
ified  and  each  module  designed  so  that  they  provide  outputs  given  specified 
inputs.  Definition  of  each  module  should  be  such  that  their  function  and 
organization  are  easily  comprehended  and  logically  complete.  Compilation  and 
assembly  of  modules  should  be  performed  in  such  a  manner  as  to  reduce  external 
references  and  allow  memory  organizations  which  enable  modifications  to  the 
program  to  be  incorporated  with  minimum  impact. 

5. 1.1. 2. 3  Module  Interaction 

Linkage  between  program  modules  and  common  subroutines  should  be  standard¬ 
ized.  Conventions  for  subroutines  linkage  should  be  defined  along  with  consist 
ent  conventions  for  the  storage  of  data  and  address  register  contents.  Program 
modules  should  respond  to  the  following:  (1)  Sequential  execution,  (2)  Inter¬ 
rupts,  or  (3)  Traps.  Subroutines  should  be  implemented  such  that  there  is  only 
one  entry  point  and  one  return  to  the  first  executable  instruction  following 
the  "call"  or  branch  instruction,  and  should  never  directly  or  indirectly  call 
or  branch  back  to  themselves.  The  capability  should  exist  to  nest  subroutines 
to  at  least  four  levels. 
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5. 1.1. 2. 4  Guidelines  for  Structural  Programming  in  Assembler  Language 

Structured  programming  techniques  can  be  applied  to  assembler  language 
programs  by  utilizing  the  macro  facility  of  the  assembler  to  generate  the 
structured  programming  constructs  or  by  simulating  the  constructs  by  annota¬ 
tion.  The  discussion  below  describes  the  annotation  technique.  The  assump¬ 
tions  made  are  that  the  assembler  language  program  is  already  structured  to 
accommodate  the  constructs: 

a)  Process 

b)  If-Then-Else 

c)  Do -While 

d)  Do -Until 

e)  Case 

In  addition,  unconditional  branches  are  utilized  only  to  satisfy  the 
constructs. 

The  notation  used  is: 

asc  -  assembler  source  code 

cond  -  condition  to  be  tested 

c  -  comments 

Each  construct  is  delineated  below. 

A.  PROCESS 

Annotate  each  process  by  partitioning  and  identifying  the  process 
code  as  follows: 

Proc 

y  «  f  (x) 
o 
o 
0 

asc  for  process 
o 
o 
o 
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END  PROC 

Partition  nested  subprocesses  (or  other  constructs)  and  identify  by 
indentation  or  enumeration.  Note  that  subprocess  does  not  imply 
every  line  of  code. 

B.  IF-THEN-ELSE 

Annotate  each  if -then-el se  construct  by  partitioning  and  identifying 
as  follows: 

If  Cond, 
o 
o 
o 

asc  for  test  and  branching 
o 
o 
o 

Then 

o 

o 

o 

asc  for  then  process 
o 
o 
o 

Else 

o 

o 

o 

asc  for  else  process 
o 
o 
o 
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Endif 


Partition  nested  if's  (or  other  constructs)  and  identify  by  in¬ 
dentation  or  enumeration. 

DO-WHILE 

Annotate  each  do-while  construct  by  partitioning  and  identifying 
as  follows: 

Do -While  cond 
o 
o 
o 

asc  for  condition  testing  and  branching  to  END  DO 
o 
o 
o 

Do-Proc 

o 

o 

o 

asc  for  Do-Process 
o 
o 
o 

End- Do 

Partition  nested  Do -While  (or  other  construct)  and  identify  by 
indentation  or  enumeration. 

Alternate  Do-While: 

Do-While  cond 
o 

asc  for  unconditional  branch  to  condition  testing 
o 
o 
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Do-Proc 

o 

o 

o 

asc  for  Do-Process 
o 
o 
o 

Do-Test 

o 

o 

o 

asc  for  condition  test  and  branching  to  Do-Proc 
o 
o 
o 

END-DO 
D.  DO-UNTIL 

Annotate  each  Do-Until  construct  by  partitioning  and  identifying  as 
follows: 

Do-Until  cond 
o 
o 
o 

asc  for  do-until  process 
o 
o 
o 
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Do -Test 


o 

o 

o 

asc  for  condition  test  and  branching  to  do-until  process 
o 
o 
o 

END-DO 

Partition  nested  do-until  (or  other  constructs)  and  identify  by 
indentation  or  enumeration. 

E.  CASE 

Annotate  each  case  construct  by  partitioning  and  identifying  as 
follows : 

Case  variable 
o 
o 
o 

asc  for  variable  testing  and  branching 
o 
o 
o 

Variable  =  Case  1 
o 
o 
o 

asc  for  Case  1 
o 
o 
o 


\f 

•L 

i  . 
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Variable  =  Case  2 


o 

o 

o 

Variable  =  Case  n 
o 
o 
o 

asc  for  case  n 
o 
o 
o 

End  case 

Partition  nested  case  (or  other  constructs)  and  identify  by 
indentation  or  enumeration. 

5.2  ONBOARD  TEST  SYSTEM  DESIGN  CRITERIA 
5.2.1  PROGRAM  ORGANIZATION  -  SERVICE  NODULES 

The  organization  of  an  onboard  test  system,  real-time  computer  program 
should  be  based  upon  the  computer  selected  (in  the  case  of  CITS- IBM  AP-2) 
and  what  the  program  has  to  do.  Hie  basic  requirements  for  the  B-.  CITS 
program  were  as  follows: 

(1)  Monitor  and  test  non-avionic  subsystems  in  the  air  and  on  the  ground. 

(2)  Provide  displays  for  system  and  the  isolated  line  replaceable  unit. 

(3)  Record  selected  parameter  values. 

(4)  Print  failure  information  on  a  strip  printer. 

(5)  Provide  inputs  to  a  crash  data  recorder  and  flight  test  recorder. 
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(6)  Interface  with  and  service  the  Avionics  Control  Unit  Complex  (ACUC) . 

The  following  is  a  typical  analysis  to  be  performed  based  on  the  above  require¬ 
ments.  In  order  to  implement  the  system  test  requirements,  the  CITS  System 
Computer  Program  had  to  provide  within  its  structure  the  functions  shown  in 
Figure  5-3,  the  mechanization  requirements  shown  in  Table  V-l,  and  the  data 
requirements  in  Table  V-2.  Test  requirements  which  have  the  greatest  influ¬ 
ence  on  the  organization  of  the  computer  program  relate  to  the  real-time  na¬ 
ture  of  test  data  acquisition,  quantity  of  data,  frequency  (rate)  required, 
and  the  time  constraints  for  testing. 

Three  different  software  structures  were  considered  for  the  B-l  CITS 
Program. 

(1)  Fixed  rate/ straight  line  -  This  method  is  characterized  by  per¬ 
formance  of  the  program  functions  in  a  linear  fashion  at  a  fixed 
rate.  Therefore,  the  entire  program  must  be  repeated  at  the  high¬ 
est  rate  required  by  any  function.  The  structure  is  linear  and  is, 
therefore,  relatively  easy  to  construct,  code,  and  document;  how¬ 
ever,  it  is  inflexible  for  the  purpose  of  modifications  and  up¬ 
dates.  It  is  not  a  good  candidate  for  future  growth  purposes. 

(see  Figure  5-4) . 

(2)  Interrupt  Control  -  This  method  utilizes  many  interrupts  to  termi¬ 
nate  one  part  of  the  program  and  enter  another.  The  interrupts  are 
assigned  priorities  which  enable  execution  of  a  desired  function  at 
the  occurrence  of  a  specific  event.  This  method  is  applicable  for 
real-time  operation  of  a  small  number  of  functions,  but  keeping 
track  of  several  levels  of  interrupts  and  associated  data  for  re¬ 
entry  may  pose  a  serious  problem.  Real-time  checkout  may  be  an 
extremely  complex  task  due  to  the  unpredictable  nature  of  the  pro¬ 
gram  (see  Figure  5-5). 


5-13 


Specified  Requirements  Block  Diagram 


TABLE  V-l  CITS  MECHANIZATION  REQUIREMENTS 


DERIVED  REQUIREMENTS  DESCRIPTION  AND  RATIONALE 

1.  Functional  Rate  and  Time  Certain  subsystems  require  monitoring  8 

Base  times  per  second  minimum  to  verify  per¬ 

formance,  while  others  may  not  require 
monitoring  more  frequent  than  every  4 
seconds  or  a  greater  interval.  The  fre¬ 
quency  of  required  monitoring  is  set  by 
individual  subsystem  need.  The  in-flight 
performance  monitor  test  requires  constant 
monitoring  of  subsystems.  In  order  to 
meet  the  requirement,  the  program  structure 
must  be  based  on  a  cycle,  within  which  all 
monitoring  and  processing  are  done  to  meet 
all  individual  subsystem  time  requirements. 
For  the  functions  which  may  not  be  needed 
except  under  special  conditions,  such  as 
fault  isolations  functions,  there  must  be 
means  to  provide  them  only  when  needed. 


2.  CITS  Hardware  and  B-l  Some  subsystems  require  waim-up  or  settling/ 

Subsystem  Compatibility  filtering  time  prior  to  actual  testings. 

Certain  subsystems  require  others  to  provide 
inputs  or  power.  A  failure  in  one  could 
result  in  a  failure  indication  in  the  other 
erroneously.  A  malfunction  in  CITS  could 
cause  a  wrong  indication  of  a  subsystem 
status.  The  program  must  be  able  to  min¬ 
imize  generation  of  such  false-alarm/no-go 
indications  by  providing  appropriate  time 
and  test  control  logic. 
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TABLE  V-l  CITS  MECHANIZATION  REQUIREMENTS  (CONT) 


DERIVED  REQUIREMENTS 

3.  CITS  Initialization 
Recovery,  Regression 


4.  Operator  Suitability 


DESCRIPTION  AND  RATIONALE 

In  order  for  the  program  to  function  cor¬ 
rectly,  the  computer  must  be  properly  ini¬ 
tialized  prior  to  entry  to  computation. 

When  an  operational  mode  change  is  comman¬ 
ded,  the  program  must  be  adjusted  to  suit 
a  new  operational  mode.  The  program  must 
be  able  to  recover  from  an  occurrence  such 
as  an  exposure  to  EMP  or  power  interruptions 
and  to  re-enter  the  operational  state.  The 
program  must  be  capable  of  operating  under 
adverse  conditions  with  possibly  less  than 
full  hardware  capabilities.  These  adapt¬ 
abilities  must  be  incorporated  into  the 
program. 

For  the  control  and  operation  of  the  CITS, 
manual  operations  must  be  minimized  and  the 
operational  procedure  must  be  simple  and 
straight  forward.  Display  and  indication 
should  be  clear,  without  ambiguity,  and 
easy  to  understand. 


i 
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TABLE  V-2  CITS  DATA  RATE  REQUIREMENTS  FOR  HARDWARE  FUNCTIONS 


FUNCTION 

DESCRIPTION 

RATE 

REASON 

Test  Data  Acquisition 

(Input) 

Test  data  acquisition  in 

time  correlated  parameter 

blocks . 

As  required 

1/sec.  to 

8/ sec.  rate. 

Sampling  rate 

for  testing 

subsystem. 

Test  Data  Request 

(Output) 

Request  for  parameter 

data. 

As  required 

1/sec.  to 

1/sec.  rate. 

Printing  and 

recording. 

Test  Data  Process 

Processing  of  data  for 

status  verification  in 

predetermined  time. 

As  required 

1/sec.  to 

8/ sec.  rate. 

Rate  for 

testing  sub¬ 
system. 

Maintenance 

Recorder 

Operational  control  and 

recording  data  output. 

As  required. 

Printer 

Operational  control  and 

alphanumeric  code  out¬ 
put. 

As  required. 

Display 

Displays  and  updates. 

4/sec. 

CCD  update. 

Mode  and  Commands 

Commands  for  tests  and 

displays,  operational 

As  required 

4/sec. 

Operator  in¬ 
put. 

mode  changes. 
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TABLE  V-2  CITS  DATA  RATE  REQUIREMENTS  FOR  HARDWARE  FUNCTIONS  (CONT) 


FUNCTION 

Peripheral  Status 
Request  Acquisition 

Stimuli  Generator 

Crash  Data  Recorder 


Flight  Test  Recorder 


DESCRIPTION! 

RATE 

REASON 

Request  for  peripheral 

equipment  status  words. 

As  required. 

Stimuli  generation  for 

subsystem  ground  test. 

As  required. 

Recording  data. 

As  required 

1/sec.  to 

8/sec. 

Recording 

Recording  data. 

As  required 

1/sec.  to 

8/ sec. 

requirement 
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COMPUTER 

INITIALIZATIOl 


DATA  SAVE 
MEMORY  AREA 


RE-ENTRY 

POINTS 


r 


< 


FIRST 

ENTRY 


INPUT 


PROCESS  JOB  1 


JOB  2 


JOB  3 


JOB  M 


JOB  N  THRU  1 

PERMMENT 

SCHEDULED 


OUTPUT 


INTERRUPT  1 
INTERRUPT  2 
INTERRUPT  3 

INTERRUPT  M 


CONDITIONS 

INTERRUPTS  ARE  PRIORITY  ASSIGNED 

INTERRUPTS  ARE  INTERRUPTABLE  BY  HIGHER  PRIORITY  INTERRUPTS 


Interrupt  Control  Program  Structure 
Figure  5-5 


5.2.1  Program  Organization  -  Service  Modules  (Cont'd) 


(3)  Multi-Rate,  Fixed  Cycle,  Modular  -  This  method  is  typified  by  its 
structure  of  modular  subprograms  which  are  grouped  by  function  and 
subsystem  test  rate.  Ihe  modular  structure  makes  for  an  easily  con¬ 
structed  program  which  simplifies  coding,  checkout,  and  documenta¬ 
tion.  Modifications  can  be  accomplished  with  relative  ease  with 
changes  to  one  module  generating  minimum  inpact  on  the  remaining 
program.  Grouping  with  respect  to  function  and  rate  allows  use  of 
comnon  subroutines  which  improve  efficiency,  process  time,  and 
reduce  memory  requirements  for  the  overall  program  structure;  how¬ 
ever,  it  is  relatively  complex  and  requires  close  coordination 
efforts.  (See  Figure  5-6). 

An  analysis  to  implement  system  test  requirements  results  in  a  method 
which  incorporates  the  optimum  features. 

A  CITS  Program  Organization  Alternate  method  summary  is  given  in  Table 
V-3.  The  method  which  offered  the  best  combination  of  features  for  the  CITS 
onboard  test  system  was  the  multi-rate,  fixed  cycle,  modular  structure  for 
the  following  reasons: 

(1)  Relative  ease  of  construction,  coding,  and  documentation. 

(2)  Modifications  and  future  growth  incorporated  with  minimum  difficulty. 

(3)  Ease  of  maintaining  real-time  control. 

(4)  Efficient  use  of  memory  by  sharing  common  subroutines. 

(5)  Ease  of  checkout  due  to  modular  structure. 

(6)  Multi-rate  scheduling  enabled  functions  to  be  assigned  at  best 
suited  duty  cycles. 

(7)  Modular  structure  enabled  functions  to  be  developed  simultaneously. 


5-21 


5-22 


TABLE  V-3  CITS  COMPUTER  PROGRAM  ORGANIZATION  ALTERNATE  METHODS  SUMMARY 


ARCHITECTURE 

ADVANTAGES 

DISADVANTAGES 

Fixed  Rate 

Relatively  easy  to  construct, 

High  duty  cycle. 

Straight  Line 

code,  and  document. 

Inefficient  usage  of 

Predictable. 

memory. 

Requires  less  data  storage. 

Inflexible  and  difficult 

to  change. 

Real-time  control  and 

system  synchronization 

difficulties. 

Difficult  to  checkout. 

Interrupt 

Inherent  priority  organ¬ 

Inherent  priority  organ¬ 

Control 

ization. 

ization  conplex  -  non- 

Fast  real-time  control 

predictable. 

for  small  number  of  jobs. 

Real-time  control  dif¬ 
ficult  for  larger  jobs 

with  many  interrupts. 

Data -save  and  re-entrant 

problems. 

Extremely  difficult  to 

checkout  (large  jobs). 

Multi  Rate 

Relatively  easy  to  code, 

Relatively  complex  struc¬ 

Fixed  Cycle 

document  at  modular  level. 

ture  -  (overall) . 

Predictable. 

Need  closer  coordination 

Efficient  use  of  memory 

and  process  time. 

Easy  to  modify  and  check¬ 
out. 

in  programming/ integration. 
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In  summary,  the  CITS  Program  consists  of  modular  multi- subprograms  grouped 
by  functions  and  subsystem  test  rates.  The  module  scheduling  is  fixed 
priority,  multi-rate,  fixed  cycle  and  non- reentrant.  The  fixed  cycle  is  one 
per  second,  divided  into  sixteen  time  slots.  Input-output  and  processing  are 
time  phased  for  balanced  and  more  efficient  usage  of  each  time  slot.  The 
real-time  test  modules  are  in  four  (4)  groups:  One  (1)  per  second;  two  (2) 
per  second;  four  (4)  per  second;  and  eight  (8)  per  second.  A  diagram  of  the 
CITS  program  organization  is  shown  in  Figure  5-7. 

5. 2. 1.1  Executive 

The  primary  function  of  an  executive  module  is  the  selection  and  subse¬ 
quent  execution  of  program  tasks  and  the  integration  of  the  total  system  by 
effectively  utilizing  the  computer  and  peripheral  capabilities  in  meeting  the 
demands  of  the  system.  In  doing  so,  the  executive  module  is  the  master  con¬ 
troller  of  the  entire  software  system.  In  performing  the  scheduling  and 
dispatching  of  functions  the  executive  module  requires  a  data  base  usually  in 
the  form  of  one  or  more  tables  containing  such  information  as  location  of 
task  programs,  priority  relationships,  conditions,  and  restrictions  under 
which  each  program  should  be  operated,  and  many  other  system  related  facts 
and  figures  including  bringing  in  needed  data  from  auxiliary  storage  if 
necessary. 

In  addition,  the  executive  module  usually  contains  a  routine  to  start-up 
or  initialize  the  system,  a  routine  to  shut  down  the  system  in  an  orderly 
manner,  and  error  handling  routines  to  allow  expedient  handling  of  system 
problems  via  interrupts.  Tne  criteria  used  for  designing  an  executive  module 
for  an  inboard  test  system  real-time  program  depends  heavily  upon  application 
information.  This  information  can  be  obtained  by  evaluating  systems  require¬ 
ments  based  upon  a  standard  set  of  objectives,  such  as  the  following: 


5-24 


CITS  Program  Block  Diagram 
Figure  5-7 
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1.  A  list  of  the  total  number  of  distinct  operational  tasks  including: 

A,  Magnitude  of  instructions  and  data  memory  requirement. 

B,  Execution  timing. 

C,  Expansion  requirement. 

2.  The  characteristics  of  each  task  including: 

A.  Priority  relationships. 

B.  Functional  relationships. 

C.  Sequential  dependency. 

3.  A  list  of  the  desired  goals  and  constraints  including: 

A.  Memory  goals. 

B.  Modes  of  operation. 

C.  Percent  of  storage  expansion  needs. 

D.  Executive  memory  allocation. 

E.  Program  organization. 

4.  Peripheral  characteristics  such  as  usage  rates  and  transfer  rates. 

5.  Critical  response  timing. 

6.  System  integrity  and  degradation. 

7.  Security  needs. 

5. 2. 1.1.1  CITS  Executive  Design  Criteria 

As  previously  described  under  Program  Organization  -  Service  Modules 
(paragraph  5.2.1)  the  CITS  operational  program  is  a  fixed  cycle,  multi-rate, 
variable-task,  real-time  program  operating  under  overall  control  of  an  execu¬ 
tive  scheduler. 
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The  following  describes  the  CITS  executive  as  a  typical  executive  based 
upon  that  structure,  residing  in  a  typical  airborne  compute  •  (IBM  AP-2). 

The  basic  rate  at  which  the  system  operates  is  16  times  per  second. 

Tasks  assigned  to  the  system  are  performed  at  rates  of  16,  8,  4,  2,  or  1  time 
per  second  depending  on  the  task.  An  exception  to  this  is  tasks  that  are  not 
executed  in  a  real-time  mode.  These  tasks  are  the  system  on/off  function, 
which  provides  a  start-up  or  securing  point  for  the  entire  program,  and  the 
system  initialization  function,  which  insures  the  operational  integrity  of 
the  CITS  system  prior  to  entering  the  real-time  domain. 

A  second  exception  to  this  is  the  I/O  servicing  function.  This  function 
is  the  software  driver  for  the  CITS  common  data  bus  over  which  all  I/O  trans¬ 
actions  between  the  prime  CITS  peripheral  equipments  and  the  CITS  computer 
take  place.  Due  to  the  hardware  design  of  this  data  bus  and  its  associated 
I/O  control  (IOC),  and  the  nature  of  some  of  the  peripheral  equipments  the 
I/O  service  function  is  executed  at  a  rate  of  64  times  per  second. 

Time  control  of  the  overall  real-time  system  and  the  I/O  service  rate  is 
accomplished  by  means  of  two  countdown  counters.  One  (center  number  1)  is 
chosen  as  the  primary  counter  and  the  other  (counter  number  2)  is  chosen  as 
the  secondary.  These  counters  decrement  at  identical  rates  of  100  microseconds 
and  generate  interrupts  which  'trap'  to  specific  locations  in  core.  Two  sep¬ 
arate  interrupt  routines  are  used.  One  is  the  executive  real-time  counter  con¬ 
trol  routine  and  the  other  is  the  I/O  service  routine. 

The  executive  real-time  counter  control  routine  is  executed  at  the  pri¬ 
mary  rate  of  16  times  per  second,  while  the  I/O  service  routine  is  executed 
at  the  secondary  rate  of  64  times  per  second.  The  selection  of  a  primary 
counter  rate  of  16  per  second  and  a  secondary  counter  rate  of  64  per  second 
was  chosen  to  allow  for  incremental  adjustments  to  the  secondary  counter 
countdown  value  without  affecting  the  primary  countdown  time  and  consequently 
the  overall  system  timing.  Phasing  between  the  two  rates  is  maintained  by 
using  the  executive  real-time  counter  control  function  to  'drive'  the  I/O 
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service  routine  initially  and  then  letting  the  I/O  service  routine  generate 
the  next  three  sequential  64  per  second  interrupts  via  the  secondary  counter. 
This  effectively  'locks’  the  two  rates  together  due  to  the  simultaneous 
countdown  feature  of  the  two  counters. 

System  simplicity  is  maintained  by  using  constant  time  values  for  both 
the  counters „  For  a  basic  rate  of  16  per  second,  the  primary  counter  time 
value  is  62,5  milliseconds.  The  secondary  counter  time  value  for  a  rate  of 
64  per  second  is  15.625  milliseconds.  This  time  value  is  unobtainable  due  to 
the  decrementation  rate  of  100  microseconds,  therefore  a  value  of  15.6  milli¬ 
seconds  is  used.  Selection  of  this  value  results  in  the  secondary  counter 
underlapping  the  primary  counter  by  no  more  than  100  microseconds  every  62.5 
milliseconds.  (4  X  15.6  msec  =  62.4  msec.)  This  underlap  time  is  used  for 
execution  of  the  executive  real-time  counter  control  function.  Figure  5-8 
presents  the  generalized  timing  scheme  used. 

Each  1/16  of  a  second  time  duration  generated  by  the  primary  counter 
interrupt  is  referred  to  as  a  time  slot  while  each  1/64  of  a  second  time 
duration  resulting  from  the  secondary  counter  interrupt  is  referred  to  as  a 
service  interval. 

Tasks  assigned  to  specific  rate  groups  are  normally  executed  in  specific 
time  slots  in  accordance  with  figure  5-9,  Since  all  tasks  are  executed  in 
real-time,  those  tasks  executed  in  a  specific  time  slot  must  be  completed 
within  the  time  interval  of  62.5  msec.  As  can  be  seen  from  Figure  5-9,  tasks 
from  two  rate  groups,  16  per  second  and  8,  4,  2,  or  1  per  second  are  executed 
in  any  one  time  slot.  Also,  1  per  second  rate  tasks  may  be  executed  in 
either  of  two  time  slots;  8  and  16.  This  feature  is  useful,  since  a  large 
percentage  of  the  operational  tasks  execute  once  per  second. 

The  task  load  may  be  distributed  more  evenly  between  time  slots  by  the 
expedient  of  offsetting  tasks  from  their  normally  assigned  time  slots.  Thus, 
if  the  load  in  the  2  per  second  time  slots  (4  and  12)  were  excessive,  some 
tasks  could  be  moved  over  to  two  of  the  4  per  second  time  slots,  provided  that 
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Prijnary  and  Secondary  Counter  Timing  Interface 
Figure  5-8 


the  rate  integrity  is  kept,  i.e.,  the  task  is  executed  every  8th  time  slot. 
A  simplified  diagram  of  the  executive  control  interface  is  shown  in  figure 
5-10. 


5. 2. 1.2  Input -Output 

Data  acquisition  for  an  onboard  test  system  is  performed  by  some  type  of 
data  acquisition  unit  (DAU) .  Similar  to  CITS,  these  might  co-exist  with 
various  types  of  numbers  of  data  dissemination  units  depending  on  the  required 
display,  print,  and  recording  capability.  All  of  these  units  are  usually 
strategically  located  on  the  aircraft.  In  tune  with  today’s  technology,  and 
as  an  improvement  to  current  CITS,  acquisition  and  storage  of  data  in  the  DAU 
memory  can  be  typically  accomplished  under  microprocessor  control.  When 
requested  by  the  main  computer,  selected  messages  are  transmitted  via  the  data 
bus.  Microprocessor  control  of  DAU  functions  eliminates  the  requirement  for 
the  main  computer  to  send  out  a  "test  point  address  word"  for  each  word  of 
data  acquired.  One  current  word  from  the  main  computer  is  the  only  comnand 
required  to  transmit  selected  data.  Input-output  bus  traffic  can  be  signi¬ 
ficantly  reduced  and  simplified.  Figure  5-11  reflects  a  typical  DAU  design 
to  meet  the  needs  of  a  typical  onboard  test  unit. 

There  are  three  basic  types  of  input-output  (I/O)  according  to  the 
method  of  controlling  and  synchronizing  data  transfer. 

1.  Program  controlled  I/O. 

2.  Interrupt  controlled  I/O. 

3.  Direct  memory  access  I/O. 

The  type  of  input-output  used  in  a  particular  onboard  test  application 
depends  on  three  main  factors: 

1.  Data  rate  required. 
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acal  DAU  Design 
Figure  5-11 


2.  Acceptable  time  delay  between  device  readiness-to-transmit  and  the 
actual  data  transfer . 

3.  Feasibility  of  interleaving  input-output  with  other  operations. 

For  an  onboard  test  sys1  ’m  application  input-output  is  required  to  take 
place  at  a  particular  instant  in  time  and/or  periodically  within  a  given  time 
frame.  The  operation  of  the  data  acquisition  or  dissemination  unit  must, 
therefore,  be  synchronized  in  real-time.  This  synchronization  may  be  achieved 
by  using  "real  time  counters"  some  or  all  of  which  may  be  programmable.  The 
program  may  then  be  interrupted  periodically  with  a  known  time  between  inter¬ 
rupts.  There  are  three  basic  types  of  interrupts. 

1.  External  interrupts  generated  from  one  or  more  I/O  devices. 

2.  Internal  interrupts  generated  by  the  computer  system  itself 
to  indicate  a  particular  event. 

3.  Simulated  interrupts  generated  by  software  to  assist  in  program 
debugging  or  interrupt  testing. 

The  different  sources  of  interrupts  have  different  servicing  requirements. 
Some  will  accept  a  delay  while  the  current  task  is  being  completed  while 
others  will  require  immediate  attention.  Therefore,  the  interrupt  service 
procedure  should: 

1.  Differentiate  between  the  various  interrupt  sources. 

2.  Prioritize  the  interrupts. 

3.  Save  and  restore  the  contents  of  registers  to  assure 

program  continuity  during  the  servicing  of  multiplex  interrupts. 

Some  onboard  test  system  applications  call  for  several  interrupt 
request  lines,  each  with  their  own  unique  trap  address.  The  problem  of 
recognition  may  be  solved  by  assigning  only  one  source  of  interrupt  to  each 
line.  This  approach  may  also  be  used  to  differentiate  between  internal, 
external,  and  simulated  interrupts. 
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In  the  majority  of  applications,  several  I/O  devices  must  use  the  same 
interrupt  request  line.  Two  methods  of  recognizing  the  source  are  commonly 
used: 

1.  Device  polling  -  the  interrupt  causes  a  jump  to  the  service  program 
via  the  trap  address.  The  service  program  then  checks  the  status 
word  of  each  device  in  turn  to  determine  which  has  caused  the 
interrupt  (see  Figure  5-12). 

2.  Vectored  interrupts  -  the  interrupt  control  logic  recognizes  the 
interrupting  I/O  device.  Each  I/O  device  is  assigned  a  unique 
"device  interrupt"  address.  Upon  recognition,  the  interrupt  control 
logic  requires  the  interrupting  I/O  device  to  transmit  its  address. 
This  address  is  then  used  to  generate  a  unique  interrupt  trap 
address  for  the  device.  The  trap  addresses  are  usually  located 
sequentially  in  program  memory  forming  the  "interrupt  vector."  Each 
location  in  the  vector  contains  the  start  address  of  a  particular 
device  service  program.  The  contents  of  the  particular  interrupt 
trap  address  are  loaded  into  the  program  counter  and  program  control 
is  automatically  transferred  to  the  service  program. 

In  some  systems  the  I/O  device  may  be  required  to  transmit  a  single  byte 
instruction  after  the  interrupt  request  has  been  acknowledged.  The  interrupt 
control  logic  would  then  automatically  load  the  instruction  into  the  instruc¬ 
tion  register  and  normal  operation  resumes  by  executing  this  instruction. 
"Interrupt  vectoring"  is  achieved  by  the  use  of  special  purpose,  single  byte 
instruction  which  derives  the  jump  address  from  a  part  of  the  code  itself. 
Using  the  device  interrupt  address  to  specify  this  bit  field,  a  unique  jump 
address  may  be  defined  for  each  device.  Device  recognition  is  performed  by 
hardware. 

With  several  interrupt  sources  there  is  always  the  possibility  of  one  or 
more  interrupt  requests  occurring  during  the  servicing  of  an  earlier  interrupt 
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request*  In  the  simpler  interrupt  systems,  the  mask  bit  is  automatically  set 
when  the  first  request  is  recognized.  Subsequent  interrupt  requests  join  a 
queue  and  wait  until  servicing  of  the  first  interrupt  has  been  completed. 

The  order  in  which  the  queued  interrupts  are  recognized  is  a  critical  factor 
in  determining  the  time  delay  before  being  serviced.  The  "priority"  may  be 
dictated  by  software  or  by  hardware. 

1*  Software  priority  -  after  recognizing  an  interrupt  request,  the 
service  program  polls  the  I/O  device  in  an  order  which  follows  the 
interrupt  priority  of  each  device.  Therefore,  the  highest  priority 
devices  are  polled  first  and  serviced  first. 

2.  Hardware  priority  -  interrupt  control  logic  can  be  used  to  send  out 
an  external  signal  which  would  control  the  interrupt  request  logic 
in  each  of  the  I/O  devices.  The  control  signal  passes  through  each 
device  in  turn  and  always  reflects  the  state  of  the  interrupt  mask 
bit.  If  the  mask  is  set,  the  signal  will  prevent  all  devices  from 
generating  at  a  device  which  has  no  interrupt  request  pending,  the 
signal  is  simply  passed  on  to  the  next  device.  When  arriving  at  a 
device  which  is  waiting  for  interrupt  service,  interrupt  logic  in 
the  device  prevents  the  signal  from  passing  on  to  the  next  device 
and  generates  an  interrupt  request.  The  position  of  a  device  along 
the  control  line  determines  its  priority.  When  more  than  one  device 
awaits  service,  the  device  which  received  the  control  signal  first 
will  be  serviced  first. 

The  problem  of  maintaining  program  continuity  in  a  multiple  interrupt 
environment  may  become  complex  especially  where  nesting  of  interrupts  occurs. 
Measures  must  be  taken  to  save  and  subsequently  restore  the  contents  of  all 
registers,  including  the  return  address  held  in  the  program  counter  for  each 
of  the  interrupt  requests  which  are  currently  being  serviced  Each  "level" 
of  service  requires  its  own  unique  storage  locations  in  which  the  information 
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can  be  saved.  The  save  and  restore  operation  may  be  implemented  in  one  of 
the  two  basic  ways: 

1.  Program  controlled  save  and  restore. 

The  contents  of  the  registers  are  transferred  to  a  unique  area  of 
memory  under  program  control  in  a  "non-interruptable"  section  at 
the  start  of  each  interrupt  service  program  before  the  interrupt 
mask  is  reset  to  allow  recognition  of  higher  priority  interrupts. 

This  information  may  be  similarly  restored  at  the  conclusion  of 
each  service  program. 

2.  Automatic  stacking. 

The  interrupt  control  logic  automatically  stores  the  contents  of 
the  registers  and  advances  a  pointer  whenever  an  interrupt  request 
is  recognized.  Upon  completion  of  servicing,  a  "return  from 
interrupt"  instruction  restores  the  registers  and  decrements  the 
pointer  appropriately. 

5. 2. 1.2.1  CITS  Input-Output  Design  Criteria 

Design  requirements  of  the  CITS  input -output  may  be  considered  a  typical 
design  for  a  fixed  cycle,  multi-rate,  variable  tasks,  real-time  program  for  an 
onboard  test  system. 

Hie  I/O  program  provides  for  the  transfer  of  data  between  the  CITS 
computer  and  the  CITS  peripherals  via  a  cornnon  data  bus.  It  consists  of  a 
program  submodule  and  a  data  submodule. 

The  program  subnodule  consists  of  the  I/O  scheduler  which  performs  the 
overall  control  functions  required  to  schedule  the  data  transfer  operations 
and  the  I/O  service  program  which  issues  the  necessary  conmands  to  the  I/O 
Controller  (IOC)  to  effect  the  physical  transfer  of  data  on  channels  1  and  2 . 

The  data  submodule  is  the  I/O  data  which  contains  all  of  the  buffers 
for  data  acquired  from  or  transmitted  to  the  peripherals.  The  data  subnodule 
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is  arranged  such  that  the  most  efficient  operation  of  the  overall  CITS 
computer  program  is  realized. 

The  overall  I/O  program  operation  is  time  phased  in  a  manner  to  meet  the 
requirements  of  the  operational  program  modules  and  the  peripheral  equipments, 
It  is  a  partially  double-buffered  function.  This  technique  was  chosen  to 
eliminate  interference  between  the  processing  operations  and  the  data  trans¬ 
mission  operations.  It  also  considerably  reduces  the  operational  program 
housekeeping  and  decision  operations. 

The  I/O  Scheduler  is  a  regularly  scheduled  function  invoked  by  the 
CITS  Executive  Control  function.  It  schedules  channel  1  I/O  for  the  next 
sequential  time  slot.  The  scheduler  consists  of  the  following  scheduling 
functions  under  control  of  a  primary  scheduler: 

1.  Self  Test  Schedule  Function 

Schedules  the  required  I/O  transactions  based  on  the  time  slot  and 
data  requests  from  the  Self  Test  module. 

2.  Data  Schedule  Function 

Schedules  the  input  parameter  acquisition  and  stimuli  issuance  trans¬ 
actions  based  on  the  time  slot  and  requests  from  operational  programs. 

3.  Control  and  Display  (CCD)  Schedule  Function 
Schedules  I/O  for  the  CCD,  based  on  the  time  slot. 

4.  Power  Control  (PC)  Schedule  Function 

Schedules  status  request  and  commands  for  the  PC  Module. 

5.  Printer  Schedule  Function 

Interrogates  and  schedules  output  to  the  Airborne  Printer. 

6.  Crash  Data  Recorder  (CDR)  Schedule  Function 

Schedules  the  required  input/output  transaction  based  on  the  time 
slot  and  recorder  availability.  In  the  event  a  CDR  hard  failure 
occurs,  all  CDR  functions  are  descheduled  except  the  recording 
function. 
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The  I/O  Schedule  functions  construct  a  temporary  Transfer  Initiate 
Command  (TIC)  stack  in  core  for  execution  in  the  next  time  slot  by  the 
I/O  service  program.  They  further  construct  the  required  Channel  Control 
Words  CCCW)  used  to  start  the  IOC  operation  for  each  block  of  TIC's. 

All  schedule  functions  examine  the  hardware  status  to  determine  if  a 
data  transaction  with  that  device  is  to  be  scheduled.  Channel  2  TIC 
scheduling  and  CCW  construction  is  a  function  of  the  Maintenance  Recorder 
CMREC)  module  and  avionics  module. 

The  I/O  service  program  submodule  is  an  interrupt  type  program.  It 
is  initiated  by  the  Executive  Real-Time  Counter  Control  function  which 
occurs  every  62.5  milliseconds  and  thereafter  via  the  secondary  real  time 
counter  interrupt .  The  I/O  service  function  is  executed  4  times  in  one 
time  slot  for  a  maximum  rate  of  64/second. 

The  Maintenance  Recorder  is  statused  controlled  and  serviced,  if  re¬ 
quired,  each  execution. 

The  number  of  messages  and  the  number  of  control  and  data  words  transmitted 
and  received  in  one  service  interval  are  limited  to  preclude  the  use  of  the 
IOC  end-of-transmission  interrupt.  These  limits  are  not  more  than  64  messages 
or  584  control  and  data  words  in  one  service  interval,  whichever  is  greater. 
These  figures  are  chosen  to  take  advantage  of  the  maximum  number  of  messages 
that  can  be  chained  together  and  to  limit  the  total  transmission  time  such 
that  the  IOC  will  be  available  at  the  next  service  interval. 

The  operation  of  the  I/O  service  routine  is  as  follows: 

1)  An  Interrupt  counter  is  reloaded. 

2)  Counter  interrupt  bit  in  the  Interrupt  Level  Status  Word  (ILSW)  is  reset. 

3)  If  it  is  the  first  service  interval: 

a)  The  I/O  Service  error  flag  and  channel  termination  bit 
is  reset. 
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b)  If  the  current  Channel  1  channel  control  word  (CCW)  location 
is  non- zero,  both  channel  1  and  2  CCW's  are  issued.  Otherwise, 
only  the  channel  2  CCW  is  issued. 

4)  If  it  is  other  than  the  first  service  interval: 

a)  If  the  I/O  service  error  flag  is  set  all  channel  1  trans¬ 
mission  scheduled  for  the  remainder  of  the  time  slot  is 
descheduled. 

b)  If  the  I/O  service  error  flag  is  not  set  the  ILSW  channel  1 
terminated  bit  is  checked.  If  channel  1  has  terminated,  the 
ILSW  bit  is  reset  and  the  channel  1  CCW  is  issued.  If  the 
channel  has  not  terminated,  the  10  service  error  flag  is  set 
and  all  transmission  for  the  remainder  of  the  time  slot  is 
descheduled. 

5)  The  internal  counters  and  pointers  are  incremented  for  the  next 
service  interval. 

6)  A  check  of  the  service  interval  count  is  made.  If  it  is  the  4th 
one  in  the  time  slot,  the  same  actions  as  3)  above  are  taken  to 
preclude  further  interrupts. 

7)  Prior  to  the  return  to  the  interrupted  operation,  the  interrupt 
status  bit  is  reset.  This  action  is  always  performed  prior  to  the 
final  exit.  The  return  is  via  the  ’old'  PSW. 

The  I/O  program  stacks  are  ordered  into  functional  groups.  Each  stack 
consists  of  two  segments,  TIC  words  and  data  words.  These  segments  are  contained 
in  separate  areas  of  core.  Stacks  containing  the  TIC's  and  data  words  to  input 
the  test  parameters  to  support  both  inflight  and  ground  testing  and  fault 
isolation  are  assigned  to  each  subsystem.  Stacks  are  also  assigned  to  the 
remaining  peripherals  that  have  permanently  scheduled  input  and  output 
operations. 

Non- Permanently  scheduled  data  (e.g.,  stimuli  and  control,  maintenance 
recorder,  special  self  test  requests)  have  core  allocated  to  hold  the 


generated  sta<  Vs  during  execution  of  the  I/O  service  function.  These  areas 
are  reusable  after  use.  Another  temporary  area  is  assigned  to  hold  the 
previously  scheduled  TIC  words  during  the  I/O  service  function  execution. 

Several  software  safeguards  were  designed  into  the  stimuli -generating 
logic  of  the  I/O  program  to  prevent  the  inadvertent  issuance  of  stimuli  to 
an  aircraft  subsystem. 

1.  No  stimuli  may  be  issued  whatsoever  on  the  ground  unless 
the  "STIMSTOP"  flag  is  non- zero.  This  flag  is  controlled 
by  the  test  select  and  sequence  control  module  (TSSC) 
which  also  determines  the  aircraft  mode  (ground  or  flight) . 

2.  All  stimuli  is  reset  upon  reinitialization  of  the  program  to 
ascertain  that  no  stimuli  were  "left  on." 

3.  In  the  air  and  on  the  ground  all  stimuli  are  "filtered"  through 
a  series  of  registers  which  ascertains  that  only  the  stimuli 
that  were  requested  is  issued. 

NOTE:  There  is  also  a  hardware  interlock  (stimuli 
button)  on  the  CCD  which  must  be  depressed 
(and  held)  for  all  critical  stimuli. 

5. 2. 1.3  Control,  Display  and  Recording 

The  basic  elements  of  a  typical  onboard  test  system  include  operator 
intervention  and  failure  and  fault  isolation  display  and  recording  capability. 

The  interface  between  CITS  and  the  operator  on  the  aircraft  is  the 
control  and  display  panel  (CCD) .  The  CCD  provides  visual  outputs  indicating 
the  status  of  the  aircraft's  operating  subsystems,  test  signal  values  and 
identification  of  failed  equipment  to  both  aircrew  and  groundcrew.  This 
information  is  presented  using  fifty  (50)  split-screen  illuminated -legend 
switch  (DELTA)  indicators,  two  hundred  and  forty-eight  (248)  illuminated -legend 
(STATUS)  indicators,  and  a  twenty  (20)  character  alphanuneric  display.  The 
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operator  can  request  changes  in  test  mode  and  display  options  as  well  as 
enter  special  data  such  as  engine  number,  date,  etc. ,  for  printing  and  re¬ 
cording  purposes.  The  CCD  panel  is  interrogated  and  updated  four  times  a 
second  for  status  changes.  This  frequency  allows  the  operator  to  read  togg¬ 
ling  information  via  the  alphanumeric  display  using  the  parameter  monitor 
function  and  also  surpasses  any  reaction  times  needed  for  operation  inter¬ 
vention.  The  delta  and  status  indicators  do  not  toggle.  The  CITS  recording 
function  retains  the  ground  and  flight  data  for  post  flight  analysis. 

5. 2. 1.3.1  CITS  Control,  Display,  and  Recording  Design  Criteria 

Several  service  modules  were  designed  to  handle  the  control  display  and 
recording  function  for  the  CITS  onboard  test  system  program.  The  following 
describes  these  modules  and  their  tasks: 

(1)  Data  Entry  and  Display  (DEAD)  Module 

The  DEAD  module  provides  the  method  by  which  the  CITS  operator  may  enter 
and  display  the  following  information. 

A.  Data  Entry.  Any  numerically  coded  data  of  ten  characters  (5  HW) 
for  the  print  and  recorder  modules. 

B.  Engine  Serial  Numbers.  Any  numerically  coded  data  preceeded  by 
engine  location,  i.e.,  one  left  outboard,  four  right  outboard. 

C.  Auxiliary  Power  Unit  (APU)  numbers.  APU  serial  numbers  one  left, 
two  right. 

D.  Aircraft  Identification.  Aircraft  tail  number. 

E.  Parameter  Monitor.  Enter  and  display  any  subsystem  parameter 
or  memory  location. 

Functional  operation  of  the  DEAD  module  is  briefly  as  follows: 

1.  The  dead  module  interfaces  with  input/output  data  to  determine  what 
mode  has  been  selected  and  whether  the  display  switch  is  in  keyboard 
or  computer  position. 
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2.  With  the  switch  in  the  keyboard  position  the  keyboard  entry  is 
processed  and  verified  to  perform  the  requested  task  which  is  to 
store  or  display  data. 

3.  With  the  switch  in  the  computer  mode  the  selected  operation  is  dis¬ 
played  on  the  alphanumeric  display. 

4.  In  parameter  monitor  mode  the  keyboard  data  is  formated  for  use  by 
the  input/output  program  to  obtain  the  selected  parameter.  Depending 
on  the  type  signal  requested  there  are  certain  lock-outs  that  are 
utilized  to  keep  from  displaying  erroneous  data  or  turning  on  a  sub¬ 
system  stimulus  inadvertently.  The  selected  parameter  is  updated  on 
the  CCD  display  four  times  per  second. 

(2)  Test  Select  and  Sequence  Control  (TSSC) 

The  CITS  onboard  test  system  operates  in  one  of  several  modes  depending 
upon  whether  the  aircraft  is  on  the  ground  or  in  the  air  and  what  the  mode 
selection  input  by  the  operator  is.  The  modes  that  CITS  recognizes  are: 

1.  Ground  ready. 

2.  Ground  fault  isolation. 

3.  In-flight  status. 

4.  In-flight  fault  isolation. 

5.  Parameter  monitor. 

6.  Date. 

7.  APU  number. 

8.  Engine  number. 

9.  Aircraft  identification. 

10.  Data  entry. 

11.  Automatic  Power  Control  (spare). 

The  TSSC  module  determines  the  mode  of  operation  and  processes  test  request 
initiated  by  the  operator.  The  module  also  determines  what  the  "true"  mode 
should  be  as  compared  to  what  the  operator  selects  by  determining  whether  the 


5-44 


aircraft  is  on  the  ground  or  in-flight  by  monitoring  such  parameters  as  weight 
on  wheels,  engines,  off/on,  etc. 

When  in  the  air,  the  in-flight  mode  indicator  is  set  and  subsystems  are 
prevented  from  receiving  conmands  for  active  tests  (which  are  only  conducted 
on  the  ground) .  An  indicator  is  also  set  instructing  the  input/output  module 
to  inhibit  the  issuance  of  stimuli  during  the  flight  mode. 

During  the  ground  mode,  TSSC  first  checks  the  "test  stop"  switch  which 
concludes  the  current  or  previous  test  and  instructs  the  input/output  module 
to  reset  stimuli  for  that  test.  It  then  checks  the  true  mode  and  sees  if  an 
active  test  is  being  commanded.  The  test  number  is  stored  and,  if  in  the  next 
time  slot  conditions  remain  valid  for  an  active  test  to  begin,  the  active  test 
bit  for  that  particular  test  is  set.  The  test  is  still  not  initiated,  however, 
until  a  final  check  is  made  to  see  that  the  "stimuli"  button  is  depressed  by 
the  operator  if  critical  stimuli  are  being  issued. 

(3)  Subsystem  Status  Interpreter  (SSIN) 

The  subsystems  status  interpreter  function  monitors  the  results  of  the 
subsystem  test  modules  for  a  change  in  status.  The  monitoring  of  each  given 
subsystem  test  module  is  scheduled  at  either  the  module  execution  rate  or  by 
direct  request  from  the  given  submodule.  The  CITS  self -test  function  is  to 
be  treated  as  a  module. 

Both  old  and  new  subsystem  status  are  contained  within  the  given  module. 
New  failures  detected  by  the  subsystem  test  modules  during  the  current  time 
slot  are  indicated  by  logical  "1"  bit  settings  in  the  appropriate  bit  positions 
in  the  new  subsystem  status  words.  Old  reoccurring  failures,  already  verified 
by  the  subsystem  status  interpreter  during  some  previous  time  slot,  are  in¬ 
dicated  by  logical  "1"  bit  settings  in  the  appropriate  bit  and  word  position 
in  the  old  subsystem  status  words.  The  subsystem  status  interpreter  compares 
the  old  subsystem  status  words  with  the  new  subsystem  status  words  to  determine 
number  of  consecutive  new  failures.  After  the  required  number  of  consecutive 
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failures,  SSIN  leaves  a  logical  ”1"  bit  set  in  the  appropriate  position  in 
the  new  subsystem  status  strings. 

Part  way  into  the  development  of  the  CITS  program  it  was  discovered 
that  a  significant  number  of  false  alarm  failure  indications  were  occurring 
for  specific  subsystems  due  to  spurious  failures  at  initial  stimuli  appli¬ 
cation  and/or  noise  in  the  system.  The  problem  was  solved  by  designing  a 
"variable  pass"  filter  in  lieu  of  the  three  pass  filter  as  was  used  up  to 
that  time.  The  variable  pass  filter  contains  logic  to  allow  the  number  of 
consecutive  out  of  limits  responses  which  would  constitute  a  failure  to  be 
unique  for  each  of  the  subsystem  modules. 

Upon  determining  that  these  consecutive  new  failures  have  occurred,  the 
subsystem  status  interpreter  also  determines  for  each  new  failure  whether  or 
not  appropriate  display  and  print  queues  have  been  previously  set  to  a  log¬ 
ical  "1".  If  the  appropriate  queues  have  not  been  previously  set,  SSIN  will 
set  them.  The  display  and  print  assemblers  utilize  these  queues  to  locate 
new  failure  and  LRU  messages  for  display  and/or  printing. 

The  subsystem  status  interpreter  monitors  a  dedicated  legend  string  in 
the  same  manner  as  the  subsystem  and  LRU  status  strings  except  for  two  dif¬ 
ferences:  (1)  the  status  bits  in  the  dedicated  legend  string  are  to  be  mon¬ 
itored  by  rate  group  instead  of  by  subsystem  and  (2)  after  detecting  three 
consecutive  new  failures,  the  corresponding  status  bits  in  the  CCD  output 
buffer  are  set  to  a  logical  "1". 

The  SSIN  function  determines  completion  of  CCD  operator  selected  ground 
readiness  tests  by  processing  status  condition  data.  SSIN  sets  a  flag  to 
illuminate  the  CCD  'TEST  COMPLETE"  legend. 

(4)  Display  Assembler  (DISP) 

The  DISP  module  sequence  of  operations  diagram  (Figure  5-13)  describes 
the  display  assembler  design.  Message  (alphanumeric  and  LRU)  to  be  displayed 
on  the  CCD  panel  are  indicated  by  the  subsystem  modules  in  subsystem  dedicated 
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bit  strings.  Each  bit  in  the  string  represents  a  unique  message.  The  sta¬ 
tus  interpreter  processes  the  indications  and  passes  the  indications  to  the 
display  assembler  module.  When  a  new  message  is  required  for  display,  the 
status  interpreter  also  sets  a  dedicated  bit  in  another  bit  string  (display 
hi- level  queue)  to  indicate  the  particular  subsystem  which  has  a  failure. 

The  display  assembler  uses  the  hi -level  queue  to  determine  when  new  failures 
have  occurred. 

To  process  the  subsystem  strings  the  display  assembler  uses  four  primary 
routines  and  a  main  line  program.  The  drivers  maintain  the  CCD  status  and 
deltas  and  call  the  primary  routine  when  required. 

The  message  assembler  routine  is  called  wheal  the  driver  has  determined 
that  a  message  must  be  displayed.  The  message  assembler  is  given  the  assembly 
location,  the  subsystem  in  which  the  message  is,  and  the  bit  number  within 
message  string  as  parameters.  The  message  assembler  uses  the  subsystem  number 
as  an  index  in  a  pointer  table,  which  in  turn  points  to  the  block  of  message 
seeds  for  the  particular  subsystem.  The  message  bit  number  index  down  the 
block  of  message  seeds  to  obtain  the  seed  for  the  particular  message  to  be 
displayed.  To  obtain  the  true  message,  the  message  seed  is  used  to  index 

into  a  dictionary  of  words.  The  words  are  assembled  into  the  buffer  location 

■> 

indicated  by  the  driver.  This  method  was  chosen  due  to  core  limitations  which 
precluded  the  use  of  pure  look-up  tables. 

The  Work  Unit  Code  Assembler  (WUCASM)  is  called  when  the  driver  deter¬ 
mines  a  work  unit  code  must  be  assembled.  The  WUCASM  routine  is  given  the 
assembly  location,  the  failed  subsystem  and  the  work  code  bit  number  as  para¬ 
meters.  The  WUCASM  obtained  the  group  number  via  indexing  into  a  table  with 
the  subsystem  number.  The  group  number  is  moved  to  the  indicated  buffer 
location.  The  work  unit  code  bit  number  is  transferred  into  a  three  character 
ASCII  number  and  assembled  in  the  buffer. 

The  STATSID  routine  is  used  to  convert  a  CCD  status  and  delta  switch  to 
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the  corresponding  subsystem.  The  STATSID  routine  is  given  a  bit  number  with¬ 
in  the  CCD  input  buffer.  The  bit  number  is  used  to  index  into  a  table  struc¬ 
ture  to  obtain  the  corresponding  subsystem.  The  subsystem  number  is  passed 
back  to  the  driver  for  use. 

The  SCANJQ  routine  is  used  to  search  the  subsystem  message  string  for 
bits  that  are  on.  The  SCANJQ  routine  is  given  a  string  code  and  subsystem 
identification  as  parameters  and  returns  a  fullword  bit  number  and  fullword 
address  and  "no  bit  on"  flag.  The  subsystem  identification  is  used  to  index 
a  subsystem  message  string  address  table  to  obtain  the  message  string  address 
and  fullword  length  for  that  subsystem.  The  string  is  then  scanned  by  fullword 
from  right  to  left  and  from  left  to  right  within  the  fullword.  The  inter¬ 
leaved  structure  of  the  message  string  is  also  condensed  in  the  SCANJQ  routine. 

Failure  messages  to  the  airborne  printer  are  generated  in  the  same  manner. 
See  Figure  5-14  for  the  display/print  design  relationship. 

(5)  Maintenance  Recorder  Assembler  (MREC) 

The  MREC  module  provides  a  means  of  assembling  CITS  parameter  data, 
maintenance  data,  and  performance  data  for  recording  on  the  CITS  Maintenance 
Recorder  (CMR) .  The  data  is  assembled  in  predefined  blocks  (records  or  frames) . 
The  process  of  assembling  each  block  of  data  shall  hereafter  be  referred  to 
as  a  job.  The  maintenance  recorder  assembler  schedules  the  jobs  in  job  queues 
by  interfacing  with  the  service  modules  and  the  test  modules.  Interfacing 
control  blocks  are  contained  in  Status  Condition  Data  (SCDATA) ,  MREC,  Print 
Assember  (PRINT)  and  Avionics -ACUC  (AVIONIX)  modules.  Jobs  will  be  assigned 
priorities  by  consideration  of  job  deferability  which  is  determined  by  data 
and  time  "freshness"  requirements  of  the  particular  jobs.  The  maintenance 
recorder  assembler  shall  execute  jobs  by  branching  to  individual  job  routines 
which  assemble  the  data  in  identical  buffers  (I0MR01  and  I0MR02)  in  IODATA. 

The  contents  of  IOMROL  and  I0MR02  each  constitute  a  long  logical  record. 
Jobs  will  not  span  buffers  (records)  in  IODATA  during  normal  "real  time" 
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processing.  The  end  of  valid  data  in  a  record  is  indicated  by  an  end  of 
record  data  frame.  The  recording  of  an  assembled  record  is  accomplished  by 
flagging  the  Maintenance  Recorder  Driver  module  (MRDRIVER)  with  a  "buffer 
full"  indication.  The  MRDRIVER  will  have  the  record  output  and  reset  the 
,fbuffer  full"  indication.  If  both  buffers  are  full  and  jobs  remain  to  be 
completed,  the  maintenance  recorder  assembler  reschedules  the  job  in  the 
next  time  slot.  MREC  includes  the  scheduling  and  assembling  of  the  follow¬ 
ing  jobs: 

1.  End  of  File  (EOF) . 

2.  Manual  Data  Entered  (MDATA) . 

3.  Permanent  Manual  Data  Entered  (PMDATA) . 

4.  Failure  Message  (FAIMSG) . 

5.  LRU  Status  Message  (LRUMSG) . 

6.  Snapshot  Data  (SNAP) . 

7.  Engine  Trend  Data  (TREND) . 

8.  Engine  Parameter  Monitor  (ENGPARA) . 

9.  Engine  Status  (ENGSTAT) . 

10.  CITS  Status  (CITSTAT). 

11.  Powered  Time  (PWRTIME) . 

12.  CITS  Calibration  (CITSCAL) . 

13.  End  of  Record  (EOR) . 

Figure  5-14  shows  the  relationship  between  the  control,  display,  and 
recording  modules. 

5. 2. 1.4  Avionics 

The  relationship  of  CITS  with  avionics,  typifies  a  possible  requirement 
for  a  remote  computer  based  system  to  perform  testing  of  its  associated  sub¬ 
systems. 


B-l  avionics  subsystem  testing  is  accomplished  by  the  avionics  computers 
in  conjunction  with  the  CITS  onboard  test  system  computer.  The  avionics  com¬ 
puters  send  test  results  to  the  CITS  computer  for  display  on  the  CITS  CCD  panel 
for  printing  on  the  airborne  printer  and  for  recording  on  the  maintenance  re¬ 
corder.  The  CITS  computer  also  processes  operator  inputs  to  avionics  via  the 
CCD.  The  interface/communication  relationship  is  such  that  the  CITS  computer 
is  the  control  or  master  computer  and  the  avionics  computers  are  the  response 
or  slave  computers. 

5. 2. 1.4.1  CITS/Avionics  Design  Criteria 

The  CITS  Dedicated  Computer  (CDC)  interfaces  with  the  Offensive  Avionics 
Control  Units  (OACU)  and  the  Defensive  Avionic  Control  Unit  (DACU)  via  the 
"AMUX  V"  communication  channel.  The  OACU  is  made  up  of  the  Weapons  Delivery 
Avionics  Control  Unit  (WDACU)  and  the  Guidance  and  Navigation  Avionic  Control 
Unit  (GNACU) .  Communication  is  serial  digital  and  is  under  control  of  the  CDC. 

The  CITS/avionics  communication  interface  provides  the  Avionics  Control 
Units  (ACU)  with  access  to  CITS  equipment  in  the  performance  of  avionics  CITS 
functions.  This  utilization  of  CITS  equipment  must  be  provided  in  a  manner 
which  will  prevent  avionic  and  CITS  conflicts  in  their  usage.  This  interface 
provides  the  ACU's  with  CITS  parameters  and  data  required  by  avionics  in  the 
performance  of  its  CITS  functions;  and  provides  CITS  with  avionic  acquired 
parameters  and  data  required  by  CITS  in  the  performance  of  its  functions.  It 
also  provides  CITS  with  avionic  acquired  crash  recorder  data.  Failures  de¬ 
tected  in  the  performance  of  these  functions  is  displayed  and  recorded  on  the 
CITS  peripherals. 

When  CITS  is  in  a  ground  mode,  the  CDC  communicates  with  the  WDACU  when¬ 
ever  it  is  on  and  the  CNACU  has  not  been  selected  as  part  of  the  ground  testing 
baseline.  When  CITS  is  in  a  flight  mode,  the  CDC  shall  carry  out  near  con¬ 
tinuous  communication  with  the  offensive  avionic  and  the  defensive  avionic 
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separate  and  independent,  however  the  message  sequence  and  structure  with 
both  are  similar. 

Communication  is  accomplished  using  23  data  messages.  Each  message  is 
assigned  a  unique  and  fixed  position  in  the  message  sequence.  Each  message 
is  assigned  a  unique  identification  correspondence  to  a  Transfer  Initiate 
Command  (TIC).  Messages  normally  cycle  through  the  complete  message  se¬ 
quence,  in  TIC  number  order,  at  a  rate  of  16  times  per  second.  These  mes¬ 
sages  and  their  TIC  identification  are  defined  in  Table  V-4.  During  normal 
communication,  the  control  word  for  each  message  is  issued  in  each  message. 
However,  data  word  portions  may  or  may  not  be  transmitted  in  each  message. 

Data  message  lengths  are  not  variable;  they  either  are  the  defined  length 
for  the  message  or  of  zero  data  word  length. 

In  non-ground  modes,  except  for  status  interrogation,  message  addressing 
by  the  CITS  CDC  is  determined  by  the  functional  status  of  the  ACU's.  Com¬ 
munication  with  the  offensive  avionic  is  with  only  one  AO  I  at  any  one  time. 

The  offensive  ACU  with  which  communication  is  to  be  carried  out  is  determined 
on  a  priority  basis.  The  priority  of  the  offensive  ACU  addressing  is:  (1) 
WDACU  and  (2)  GNACU.  The  CDC  uses  the  ACU  status  indications  from  EMUX  to 
determine  when  to  attempt  communications  with  an  ACU.  If  CITS  is  in  a  ground 
mode  and  an  avionic  power  controller  baseline  has  been  selected,  the  CDC  will 
only  attempt  to  communicate  with  the  ACU's  corresponding  to  the  selected  base¬ 
line.  At  any  other  time,  when  the  CDC  determines  that  an  ACU  is  on,  the  prop¬ 
er  communication  has  not  been  established  with  the  other  ACU,  and  CDC  will 
attempt  to  establish  communications  with  the  ACU.  After  30  seconds  fol¬ 
lowing  the  detection  of  the  ACU  on  indication,  proper  coumunication  has  not 
been  established,  the  CDC  indicates  there  is  a  communication  fault. 

Each  message  is  initiated  by  the  CDC  issuing  a  control  word.  The  Tran¬ 
sfer/Receiver  (T/R)  bit  status  of  each  control  word  shall  be  checked  by  the 
addressed  ACU  for  agreement  with  the  T/R  status  expected  for  that  message. 

The  CDC  sets  the  control  word  count  to  zero  when  data  transmission  is  not 
required. 
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There  are  four  control  words  for  each  TIC,  the  third  and  fourth  of  which 
are  dummy  words  to  insure  a  minimum  of  at  least  24  microseconds  between  trans¬ 
mission  of  consecutive  control  or  data  words  to  a  given  ACU. 

Data  indicating  communication  status  with  the  ACU's  and  flight  test  re¬ 
corder  shall  be  handled  on  Channel  number  1.  All  ACU/CITS  interface  data  is 
handled  on  Channel  number  2. 

5. 2. 1.5  Ground  Readiness  Tests  (GRT's)  and  Power  Control  CPC) 

The  following  typifies  an  approach  to  ground  testing  as  accomplished  by 
the  onboard  test  system. 

GRT's  (active)  are  performed  utilizing  the  CITS  to  verify  system  per¬ 
formance  and  to  reverify  system  operation  after  a  maintenance  action  has  been 
performed  on  the  aircraft.  These  GRT's  are  automatically  conducted  under 
CITS  computer  control  and  require  between  one  second  and  five  minutes  to 
conduct.  The  ground  crew  can  run  the  GRT's  in  either  one  of  two  modes  of 
operation.  The  first  is  the  manual  power  control  mode  in  which  the  aircraft 
test  configuration  is  manually  set  up  by  the  ground  crew.  This  is  accomp¬ 
lished  by  opening/ closing  circuit  breakers  and  positioning  cockpit  dials  and 
switches  to  enable  system  under  test  and  supporting  systems  operation.  This 
mode  is  used  when  the  aircraft  is  being  supported  by  ground  power  and  cooling 
carts.  In  this  mode,  other  testing  can  be  performed  in  parallel  with  the 
CITS  GRT.  In  order  to  comply  with  the  self-sufficiency  requirements  necessary 
for  an  advanced  manned  strategic  aircraft,  a  second  mode,  automatic  power 
control,  of  running  GRT's  is  required.  In  this  mode,  the  CITS  computer  sets 
up  the  power  and  cooling  configuration  of  the  aircraft  by  controlling  the 
operation  of  the  B-l  EMUX  system  through  its  Boolean  logic  equations.  When 
the  aircraft  is  in  the  automatic  power  control  mode,  CITS,  through  EMUX, 
automatically  sets  up  the  aircraft  baseline  power  and  cooling  configuration. 
When  the  CITS  operator  wants  to  conduct  a  particular  subsystem  test ,  he 
enters  the  subsystem  code  into  the  CITS  computer  using  the  control  and  display 


keyboard.  The  computer  then  reconfigures  the  aircraft  power  and  cooling  to 
support  the  test  selected.  As  soon  as  the  power  and  cooling  is  configured 
to  support  the  selected  test,  an  operator  message  'Test  Power  Configuration 
Set"  is  displayed  on  the  control  and  display  alphanumeric  display,  and  the 
operator  can  then  proceed  to  conduct  the  test.  At  the  conclusion  of  the  test, 
the  power  and  cooling  is  returned  to  the  aircraft  baseline  configuration. 

The  automatic  power  control  mode  is  designed  to  allow  aircraft  subsystem 
testing  to  be  accomplished  supported  by  the  onboard  electrical  power,  hy¬ 
draulic  power,  and  equipment  cooling.  Because  of  this,  the  total  power  and 
cooling  load  must  always  be  maintained  within  the  limits  of  the  secondary 
power  system.  Of  prime  importance  in  using  the  CITS  concept  is  getting  the 
system  into  use  by  field  test  personnel  as  quickly  as  possible  during  the 
flight  test  program.  This  allows  interface  problems  to  be  identified  and 
corrected  while  the  subsystems  are  still  in  the  development  stage.  During 
the  flight  test  program,  equal  importance  for  test  and  troubleshooting  time 
must  be  given  the  onboard  test  system  as  any  other  major  onboard  system. 
Without  this  consideration,  onboard  test  system  hardware/software  development 
will  be  lagging  and  test  results  will  not  be  available  to  evaluate  the  ef¬ 
fectiveness  of  the  onboard  test  system. 

5. 2. 1.5.1  CITS  GRT's  and  PC  Design  Criteria 

The  PWRCNTRL  module  performs  several  functions  to  accomplish  the  module 
requirements . 

There  are  three  PC  modes  which  can  be  established:  1)  Passive  Testing 
Made,  2)  Pseudo  Power  Controller  Made,  and  3)  True  Power  Controller  Control 
Mode. 

When  a  passive  testing  mode  or  psuedo  power  controller  mode  is  deter¬ 
mined,  the  test  modules  ompatible  with  the  existing  load  management  mode 
for  passive  testing  are  scheduled  after  a  ten  second  delay. 


When  a  true  PC  control  mode  is  determined,  the  aircraft  baseline  state 
for  the  power  controllers  is  established  for  the  left  and  right  EMLJX  by  is¬ 
suing  commands  which  disable  than,  enable  them,  or  turn  than  on  or  off.  Com¬ 
mands  for  the  left  and  right  side  are  issued  to  establish  load  management 
mode  5.  Next,  a  bit  is  set  to  have  the  CCD  display  indicate  "AIRCRAFT  BASE¬ 
LINE.”  Then  the  CITS  test  modules  compatible  with  the  aircraft  baseline  are 
scheduled  after  a  10  second  delay. 

The  PWRCNTRL  mode  tests  a  code  entry  from  the  CCD  keyboard  for  validity 
and  for  function.  CCD  keyboard  entries  are  accepted  for  checking  when  the 
CCD  mode  select  switch  is  found  in  either  the  ground  ready  or  the  ground 
fault  isolation  position,  and  the  CCD  test  switch  is  found  to  be  placed  in 
the  STOP  position,  and  then  when  the  CCD  select  switch  is  placed  in  KYBD 
position. 

After  these  initial  checks,  analysis  occurs  regarding  entry  validity 
and  entry  function. 

If  an  aircraft  test  code  or  an  avionics  baseline  set  or  reset  code  has 
been  entered,  and  the  entry  is  found  invalid,  or  the  configuration  is  in¬ 
compatible  with  the  power  source,  the  CCD  display  will  snow  the  word  "INVALID" 
and  the  invalid  entry.  The  module  will  then  await  the  next  function  or  entry 
for  analysis.  If  the  entry  is  found  to  be  valid,  and  the  configuration  is 
compatible  with  the  power  source,  the  CCD  display  will  show  the  word  ’VALID" 
with  the  valid  entry.  Thai,  when  the  CCD  select  switch  is  placed  in  the 
CMPTR  position  followed  by  the  CCD  test  switch  placed  on  START,  the  active 
aircraft  test  or  an  avionics  baseline  set/reset  shall  occur. 

5.3  ESTIMATION  TECHNIQUES 

It  is  essential  to  be  able  to  estimate  the  time  phasing  and  size  of  the 
onboard  test  system  program  early  in  the  development  process.  The  following 
discusses  some  estimating  approaches  based,  for  the  most  part,  on  the  expe¬ 
rience  gained  from  the  CITS  program. 
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5.3.1  TIMING 


A  time -phasing  analysis  was  made  soon  after  the  start  oC  the  CITS  pro¬ 
gram.  This  analysis  serves  here  as  a  recommended  approach  to  evaluating  the 
data  input,  processing  and  output  timing  approach  for  a  typical  onboard  test 
s>3tem,  real-time  computer  program.  In  the  case  of  CITS,  the  data  transfers 
considered  were  between  the  computer  and  the  air  vehicle  non -avionics  sub¬ 
systems  and  CITS  peripherals  which  include  the  control  and  display,  airborne 
printer,  and  maintenance  and  crash  data  recorders. 

The  general  requirements,  using  CITS  as  an  example,  are  as  follows: 

The  CITS  Computer  Program  shall,  at  required  real-time  rates,  control 
test  modes,  test  sequencing,  rates,  timing,  test  data  acquisition,  processing 
and  transfer,  and  test  results  display  and  recording  to: 

A.  Test  and  verify  the  RDT§E  air  vehicle  subsystems  both  in-flight 
and  on  the  ground.  The  test  frequency  rate  of  functional  tests 
shall  provide  a  continuous  indication  of  subsystem  performance 
to  the  aircrew. 

B.  Display  to  the  aircrew,  subsystem  failure  information. 

C.  Provide  onboard  identification  and  isolation  of  LRU's. 

D.  Provide  selected  test  data  and  test  results  for  identification  and 
isolation  of  a  failed  LRU  on  the  ground. 

The  quantity  of  data  (16  bits  per  word)  transferred  between  the  CITS  pro¬ 
cessor  and  CITS  peripheral  equipment  are  as  follows: 

A.  Thirty-three  words  of  output  at  a  cycle  rate  of  4  times  per  1  second 
cycle  from  the  processor  to  the  CITS  control  and  display  for  display 
of  the  status  of  air  vehicle  subsystems  tests. 

B.  Ten  words  of  input  at  a  cycle  rate  of  4  times  per  1  second  time  cycle 
from  the  CITS  control  and  display  to  processor  for  test  selection 
and  mode  control. 

C.  Two  characters  per  word,  25  characters  per  second  maximum  are  output 
from  the  processor  to  the  CITS  printer. 
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D.  Six  thousand  two  hundred  and  fifty  words  per  second  maximum  are 
transferred  from  the  processor  to  the  maintenance  recorder. 

The  quantity  of  test  parameters  transferred  from  the  air  vehicle  sub¬ 
systems  to  the  processor  are  listed  in  Table  V-5  by  signal  type  for  the  in¬ 
flight  performance  monitoring  mode.  Similar  lists  should  be  made  for  each 
mode  of  operation. 

The  test  data  representing  the  test  control  and  stimuli  are  output  to 
the  air  vehicle  subsystems  as  required.  The  quantity  of  stimuli  required 
for  each  subsystem  is  listed  on  Table  V-6. 

The  air  vehicle  subsystems  test  parameters  are  monitored  by  CITS  at  the 
data  cycle  rates  listed  on  Table  V-7. 

5. 3. 1.1  Analysis 

The  CITS  Computer  Program  inputs,  processing,  and  output  operations  are 
time-phased  as  shown  in  Table  V-8.  Each  time  cycle  is  1  second  and  is  divided 
into  16  time  slots.  Each  time  slot  is  62.5  ms.  The  time  phased  operations 
are  as  follows: 

A.  Data  is  input  in  time  slot  t. 

B.  This  data  is  processed  in  time  slot  t  +  1. 

C.  Data  required  to  be  output  as  a  result  of  the  processing  is 
accomplished  in  time  slot  t  +  3. 

All  scheduled  real-time  functions  in  each  time  slot  must  be  completed 
within  the  time  slot. 

In  this  analysis,  the  data  input,  processing  and  output  times  will  be 
determined  for  each  time  slot  based  on  currently  available  information. 

Table  V-9  lists  the  time  required  to  input  test  parameters  from  the  non¬ 
avionics  subsystems  in  time  slots  1  through  16.  This  information  is  based  on 
an  input/output  simulation  program  which  determines  the  time  required  to  in¬ 
put  test  parameters  from  each  subsystem  based  on  input/output  data  size,  in¬ 
put/output  stack  size,  and  number  of  messages. 
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TABLE  V-6  STIMULI  AND  CONTROLS  OUrPUT  TO  A/V  SUBSYSTEMS 
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TABLE  V-7  A/V  SUBSYSTEM  DATA  CYCLE  RATES  PER  SECOND 


\¥ 


CITS  COMPUTE  TINE  CYCLE 


Output  Data 
Process  Data 


TABLE  V-9  ESTIMATED  CITS  PROGRAM  MODULE  EXECUTION  TIMES 


Module 

Execution  Time  (MS) 
Per  Time  Slot 

Executive 

0.4 

Test  Select  and  Sequence  Control 

2.0 

System  Error  Control 

1.5 

Back-Up  Mode  Control 

0.5 

I/O  Program 

5.0 

Data  Enter  and  Display 

1.5 

Flight  Test  Data  Driver 

0.5 

Subsystem  Status  Interpreter 

3.0 

CITS  Self-Test 

2.0 

CITS  Computer  Monitor 

1.0 

Display  Assembler 

4.0 

Print  Assembler 

1.5 

Maintenance  Record  Assembler 

1.0 

Total 

23.9 
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TABLE  V-9  (CONT) 
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Table  V-10  lists  the  time  required  to  output  stimuli  and  controls  in 
time  slots  1  through  16  and  identifies  the  time  required  for  each  subsystem. 
The  time  figures  were  obtained  from  the  input/output  simulation  program. 

Based  on  sample  algorithms  for  air  vehicle  subsystems  performance  test 
and  using  programming  instructions  for  IBM  Model  AP-2  Computer ,  the  average 
processor  time  required  for  processing  test  parameters  was  estimated  to  be 
as  follows: 


Parameter  Type 
Discrete  (Miltiple  of  16) 
Digital 
Analog  (DC) 


Processing  Time 
30  microseconds 
140  microseconds 
140  micorseconds 


Based  on  the  above  processing  rates,  tiie  processor  time  required  for 
processing  test  parameters  was  calculated  using  the  test  data  parameter 
list.  The  calculated  figures  are  listed  in  Table  V-ll  and  are  grouped  by 
time  slot.  The  figures  listed  under  in-flight  fault  isolation  and  ground 
fault  isolation  are  the  time  required  to  process  additional  test  parameters 
for  fault  isolation  routines. 

Table  V-12  lists  the  estimated  execution  times  for  each  program  module 
other  than  the  subsystems  performance  tests.  This  is  the  approximate  time 
required  in  each  time  slot  for  in-flight  and  ground  tests. 

Having  computed  the  time  for  test  parameters  input,  output  and  processing 
in  each  time  slot,  all  input/output  data  can  be  summarized  in  time  slot  shown 
in  Table  V-13. 


5. 3. 1.2  Analysis  Summary 

In  sequential  operation,  the  input,  processing  and  output  occur  in  se¬ 
quence;  when  one  is  active,  the  others  are  idle.  In  overlapped  operation, 
input/process  or  output/process  may  occur  concurrently.  Thus  in  overlapping 
operation,  the  total  time  required  for  input/output  and  process  will  be  less 
than  for  sequential  operation.  The  time  required  for  sequential  and  over¬ 
lapped  operations  are  listed  on  Tables  V-14  through  V-17. 
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TABLE  V-10  TIME  REQUIRED  TO  PROCESS  A/V  SUBSYSTEMS  TEST  PARAMETERS  IN  TIME  SLOTS  1  THROUGH  16 


N  H  O  CO  N  M  CO 

N  N  o  \D  H  N  in 

rH  O  O  O  tO  i— |  t"- 


O 

00 


H  00  N  fQ  fQ 
Oi-H’or'-'-Orj- 

O  rH  O  O  rH  O 


O 

OO 

00 


1 o 

CM 

Csl 

O 

00 

vO 

o 

rH 

rH 

00 

«h 

O 

to 

O 

O 

LO 

to 

00 

OO 

to 

•*3- 

to 

rH 

to 

CM 

o 

LO 

CM 

to 

LO 

VO 

00 

CM 

to 

cm 

cm 

o 

CT) 

to 

© 

© 

to 

LO 

H- 

vO 

to 

rH 

o 

r^. 

to 

r- 

<N| 

o 

CM 

o 

LO 

o 

to 

cm 

CM 

to 

rH 

to 

VO 

CM 

O 

o 

o 

rH 

rH 

rH 

rH 

rH 

HH  £-< 


Is**  to  o  t^> 

N  VO  O  rj 


CM  CNJ 

to  r^ 


«— I  O  O  o  O  rH 


i— <  o  r- 1  oo  oi  n  ro  to 

^  00  o  «— I  N  O  rf 

l^t  00  Of-HOOrHO 


O 

00 


l/)  N  vO  rf 
OO  VO  LO  H 


rH  O  tO  O  O 


to 

<M 


o  o 

rH  O 


^  N  O  H 


LO 

rH 

to 


O* 

r- 

LO 

to 


to 

rfl 

|r- 

rH 

to 

CM 

o 

LO 

CM 

to 

Ilo 

rH 

VO 

OO 

LO 

rH 

LO 

o 

tM 

ho 

to 

o 

0\ 

to 

LO 

ti* 

rf 

IvO 

to 

rH 

O 

o 

^3* 

to 

LO  I 

rH 

o 

to 

o 

to 

cm 

cm 

to 

rH 

to 

VO 

CM 

»H 

o 

o 

I  *H 

rH 

rH 

rH 

rf  ^  ^  tj*  rj* 


00  00  00  00  00 


4-> 

§ 

u 

■« 

£ 


S3 

■M 

O 

E— 


| 


©■5 . 

U  P  H 


3  C 

C9  P 
>■  C/3 


•*H 

ft 


t/> 

<D 

C 

•H 

if 


SI 


V)  (/3 

P  AC 

w  u 

rH  Cfl 

c/3  a 
o. 

33  T3  - 

-PrH  %  §  £ 

3  a,  C/3  33  CO 

c«  vi  u  P 

H  2  2&S  8 
12  S  £2  .3  * 


U  +3 
•rH  O 


rt 

p 

H 


P 

1 


7) 

V) 

2 


0) 

u 


fS 


fr-o 

il! 

i  33  -H 
W  C/3  < 


II 

c n  3) 

03  -5 

4h 


•M 

£ 


5-67 


.  vow-  .  -  . 


TABLE  V-ll  TIME  REQUIRED  TO  OUTPUT  STIMULI  AND  CONTROLS  TO  A/V  SUBSYSTEMS  IN  TIME  SLOTS  I  THROUQ  f  16 
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TABLE  V-12 


Time  required  to  input  test  parameters  from  A/V  subsystems  in  time  slots  1 
through  16.  Applicable  to  in-flight  performance  in-flight  fault  isolation, 
ground  readiness  and  ground  fault  isolation  test.  Time  figures  are  in  milli¬ 
seconds. 


SUBSYSTEM 

TIME  SLOT  NO. 

TIME  (MS) 

Engines 

1 

7.30 

Decel 

2,4,6,8,10,12,14,16 

1.85 

Pitch 

1.00 

Roll 

0.20 

Yaw 

1.00 

St rue  Mode  Cont 

1.60 

Spoilers 

2.30 

Total 

7.95 

Flight  Direc  Comp 

3 

0.15 

Hdraulic  Power 

3 

1.50 

Fire  Protect 

3 

1.05 

Wing  Sweep 

3 

1.20 

Flaps  and  Flats 

3 

1.55 

Launch,  Racks,  Doors 

3 

0.75 

Total 

6.20 

Engines 

5 

7.30 

E-MUX 

7 

2.30 

Secondary  Pwr 

7 

1.00 

Air  Cond/Press 

7 

2.00 

Life  Support 

7 

0.30 

Engine  Anti- Ice 

7 

0.35 

Total 

5.95 

Engines 

9 

7.30 

RCA 

11 

0.70 

Bleed  Air 

11 

1.05 

Environ  Prot 

11 

0.20 

Escape  Sys 

11 

0.35 

AICS 

11 

3.90 

Flaps  and  Slats 

11 

1.55 

Launch,  Racks,  Doors 

11 

0.75 

Total 

8.50 

Engines 

13 

7.30 
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TABLE  V-13  TINE  REQUIRED  TO  INPUT  AND  OUTPUT  DATA  FOR  IN-FLIGHT  PERFORMANCE  M3NITORT NG  AND  FAULT  1SOIATION. 

TIME  FIGURES  ARE  IN  MILLISECONDS 
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In  overlapping  operation,  a  delay  may  occur  in  honoring  memory  access 
request  due  to  cycle  stealing  by  the  input/output.  Therefore,  the  processing 
time  was  increased  by  10  percent. 

The  total  time  required  in  each  time  slot  of  1  second  time  cycle  is 
summarized  in  Tables  V-16  and  V-17  for  In-Flight  Performance  Monitoring  and 
Fault  Isolation  and  in  Tables  V-14  and  V-15  for  Ground  Readiness  and  Fault 
Isolation  Tests. 

The  total  time  shown  is  for  worst  case  condition  where  primary  mode  and 
fault  isolation  routines  are  to  be  performed  on  every  subsystem  scheduled 
in  that  time  slot  and  data  is  to  be  outputted  to  the  printer,  recorders,  and 
CITS  control  and  display. 

Tables  V-14  through  V-17  indicate  that  for  both  in-flight  and  ground 
tests,  the  62.5  ms  time  period  is  exceeded  in  some  time  slots  if  the  operation 
is  sequential  and  that  overlapped  operations  will  allow  the  completion  of  the 
scheduled  operations  within  the  62.5  ms  period  with  some  slack  time.  Further 
indications  are  that  optimum  utilization  of  time  will  be  accomplished  if  some 
adjustments  are  made  in  the  data  cycle  rates  where  possible. 

5. 3. 1.3  Conclusions 

The  following  conclusions  are  arrived  at  from  this  example: 

A.  Overlapping  of  processing  and  input/output  functions  is  required  to 
adjust  time  load  between  time  slots. 

B.  Adjustment  of  test  rates  is  required  to  equalize  input/output  and 
processing  time  per  time  slot. 

C.  Optimization  of  input/output  is  necessary. 

The  time  structure  shewn  in  Tables  V-15  and  V-17  is  the  design  point  for 
the  CITS  computer  program. 
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injiLL  V-14  OVERLAPPED  OPERATIONS  (I/O  AND  PROCESSING) 
FOR  GROUND  READINESS  AND  FAULT  ISOLATION 


time 

SLOT 

NUMBER 

PROCESSING 

TIME 

(PROCESS  BOUND") 

1 

46.87 

2 

47.66 

3 

46.87 

4 

41.92 

5 

46.87 

6 

47.66 

7 

46.87 

8 

40.47 

9 

46.87 

10 

47.66 

11 

46.87 

12 

41.13 

13 

46.87 

14 

47.66 

15 

46.87 

16 

45.13 

TOTAL 

734.25 

CYCLE 

STEALING 

TOTAL 

I/O  PROCESS 
TIME 

4.68 

51.55 

4.76 

52.42 

4.68 

51.55 

4.19 

46.11 

4.68 

51.55 

4.76 

52.42 

4.68 

51.55 

4.04 

44.51 

4.68 

51.55 

4.76 

52.42 

4.68 

51.55 

4.11 

45.24 

4.68 

51.55 

4.76 

52.42 

4.68 

51.55 

4.51 

49.64 

73.33 

807.58 
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TABLE  V-15  SEQUENTIAL  OPERATIONS  (I/O  AND  PROCESSING) 
FOR  GROUND  READINESS  AND  FAULT  ISOLATION 


TIME 

SLOT 

NUMBER 

DATA 

I/O  TIME 

DATA 

PROCESS 

TIME 

TOTAL 

I/O  PROCESS 
TIME 

1 

23.34 

46.87 

70.21 

2 

22.49 

47.66 

70.15 

3 

20.29 

46.87 

67.16 

4 

22.25 

41.92 

64.17 

5 

23.34 

46.87 

70.21 

6 

21.44 

47.66 

69.10 

7 

19.27 

46.87 

66.14 

8 

21.66 

40.47 

62.13 

9 

23.34 

46.87 

70.21 

10 

21.19 

47.66 

68.85 

11 

22.34 

46.87 

69.21 

12 

22.06 

41.13 

63.19 

13 

23.34 

46.87 

70.21 

14 

22.34 

47.66 

70.00 

15 

21.92 

46.87 

68.79 

16 

22.77 

45.13 

67.90 

TOTAL 

353.38 

734.25 

1087.63 
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TABLE  V-16  OVERLAPPED  OPERATIONS  (I/O  AND  PROCESSING)  FOR 
IN-FLICHT  PERFORMANCE  AND  FAULT  ISOLATION 


TIME 

SLOT 

NUMBER 

PROCESSING 

TIME 

(PROCESS  BOUND) 

CYCLE 

STEALING 

TOTAL 

I/O  PROCESS 
TIME 

1 

42.44 

4.24 

46.68 

- 

47.66 

4.76 

52.42 

3 

42.44 

4.24 

46.68 

4 

41.92 

4.19 

46.11 

5 

42.44 

4.24 

46.68 

6 

47.66 

4.76 

52.42 

7 

42.44 

4.24 

46.68 

8 

40.26 

4.02 

44.28 

9 

42.44 

4.24 

46.68 

10 

47.66 

4.76 

52.42 

11 

42.44 

4.24 

46.68 

12 

47.32 

4.73 

52.05 

13 

42.44 

4.24 

46.68 

14 

47.66 

4.76 

52.42 

15 

42.44 

4.24 

46.68 

43.05 

4.30 

47.35 

TOTAL 

702.71 

70.20 

772.91 
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TABLE  V-17  SEQUENTIAL  OPERATION  (I/O  AND  PROCESSING) 
FOR  IN-FLIGHT  PERFORMANCE  AND  FAULT  ISOLATION 


TIME 

SLOT 

NUMBER 

DATA 

I/O  TIME 

DATE 

PROCESS 

TIME 

TOTAL 

I/O  PROCESS 
TIME 

1 

19.78 

42.44 

62.22 

2 

21.44 

47.66 

69.10 

3 

18.49 

42.44 

60.93 

4 

22.25 

41.92 

64.17 

5 

21.54 

42.44 

63.98 

6 

20.99 

47.66 

68.65 

7 

17.47 

42.44 

59.91 

8 

21.66 

40.26 

61.92 

9 

21.54 

42.44 

63.98 

10 

20.99 

47.66 

68.65 

11 

20.54 

42.44 

62.98 

12 

22.06 

47.32 

69.38 

13 

21.54 

42.44 

63.98 

14 

20.99 

47.66 

68.65 

15 

20.12 

42.44 

62.56 

16 

22.77 

43.05 

65.82 

TOTAL 

334.17 

702.71 

1036.88 
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5.3.2  MEM5RY 

A  CITS  computer  memory  sizing  analysis  was  made  soon  after  the  start  of 
the  CITS  program.  This  analysis  serves  as  a  recommended  approach  to  eval¬ 
uating  the  memory  required  for  a  typical  onboard,  real-time  computer  program. 

The  basic  considerations  for  this  study  involved  the  following  general 
requirements : 

1.  The  CITS  Computer 

A  general  purpose,  small-scale  airborne  computer  capable  of  per¬ 
forming  the  functions  described  below. 

2.  The  Program  Requirements 

Performance  functions  of  test  mode  control,  test  data  acquisition 
and  transfer,  test  data  processing,  and  test  result  display.  Also, 
to  contain  test  logic,  test  sequencing  in  real-time,  go/no-go  de¬ 
cision  data,  necessary  computational  routines  and  peripheral  equip¬ 
ment  controls. 

3.  Program  Structure 

Simple  and  functional,  constructed  in  modular  form  to  simplify  soft¬ 
ware  development  and  functional  verification,  with  multi-rates  to 
meet  various  timing  requirements. 

5. 3. 2.1  Sizing  Methodology 

Analysis  of  storage  requirements  was  accomplished  by  identifying  the 
various  program  functions,  program  design,  and  test  requirements  data,  de¬ 
fining  the  functions,  applying  appropriate  estimating  methods,  and  performing 
the  necessary  calculations. 

5. 3. 2. 1.1  Assumptions  and  Conditions 

The  following  assumptions  and  conditions  were  made  regarding  the  program 
environment  and  characteristics: 
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1.  A  real-time  program  using  a  small-scale  general  purpose  airborne 
digital  computer  utilizing  a  16-bit  word  format. 

2.  Easily  modifiable  program,  compatible  with  future  hardware. 

3.  Modular  constructed  program,  fixed  cycle,  multi-rate. 

4.  No  assumed  unique  capability  or  characteristics  of  a  computer 
which  may  not  exist  at  a  later  date. 

5.  Where  data  or  requirements  are  not  definitized,  available  information 
and  engineering  judgement  employed  to  derive  best  estimate  to  base 
the  analysis. 

6.  Approximately  25  percent  of  total  memory  allotted  for  inaccuracies 
in  preliminary  analysis  and  for  future  growth. 

7.  Inefficiency  due  to  utilizing  less  than  16 -bits  per  word  for  computer 
operation  considered  and  accounted  for. 

8.  Assumed  LRU  specified  in  work  unit  code  documentation. 

9.  Display  messages  as  indicated  in  requirements  documentation. 

5. 3. 2. 1.2  Sources  of  Information 

The  factors  used  in  the  estimating  process  were  derived  from  the  following 
sources : 

1.  The  program  requirements  as  defined  in  CITS  requirement  analysis 
package. 

2.  The  data  requirements  as  represented  by  the  subsystem  parameter 
data,  the  display  and  recording  requirements,  and  constants  required 
for  special  functions  such  as  interrupts,  control  words,  initilization, 
parameter  limits,  and  computations. 

3.  The  airborne  computer  characteristics  from  the  manufacturers  manuals. 

5. 3. 2. 1.3  Methods 

Two  basic  methods  were  utilized  in  estimating  the  amount  of  storage  re¬ 
quired  by  the  CITS  program. 
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1.  Calculation  method  -  used  where  the  requirements  are  relatively  de- 
finitized.  The  following  steps  outline  the  method: 

A.  Determine  test  algorithms  from  program  requirements  and  tabulate 
by  similar  functional  process  groups. 

B.  Using  generalized  instructions  available  in  any  computer  deter¬ 
mine  a  base  for  required  number  of  instructions  to  perform  the 
particular  functions. 

C.  Multiply  these  numbers  by  the  number  of  repetitions  for  the 
function  to  derive  the  total  for  a  type  of  process. 

D.  Sum  the  processes  to  obtain  the  total  requirement  for  a  sub 
program. 

2.  Estimating  method  -  used  where  the  requirements  are  not  definitized. 
The  steps  for  using  this  method  are  outlined  below: 

A.  Use  best  available  information  and  engineering  judgement  to 
estimate  the  number  and  type  of  process  required. 

B.  Estimate  the  number  of  computer  words  required  to  implement 
each  process. 

C.  Multiply  the  number  of  words  for  each  process  by  the  estimated 
number  of  repetitions. 

D.  The  sum  of  the  memory  requirements  for  each  process  will  give 
the  estimated  memory  requirement  for  each  subprogram. 

Subprograms,  such  as  utility  routines,  can  be  estimated  from  existing 
programs  for  similar  type  computers  executing  similar  functions. 

5. 3. 2. 2  Sizing  Analysis 

An  outline  of  a  typical  onboard  real-time  test  program,  by  subsystem 
modules,  can  be  described  as  follows: 

1.  Program  Execution  Modules 

A.  Service  Routines 

B.  Subsystem  Test  Routines 

C.  Utilities  and  Subroutines 

i 


I 
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2.  Data  and  Working  Storage  Area. 

A.  Machine  Reserved 


B.  Data  Storage 

C.  Input/Output  Data  Area 

D.  Data  Buffers  for: 

Input/Output 

Display 

Printer 

Recorders 

E.  Working  Storage 

3.  Area  Reserved  for  Growth 

Each  of  the  above  are  discussed  separately.  The  method  used  and  the  fac¬ 
tors  involved  in  the  CITS  computer  sizing  analysis  are  included  as  examples : 

At  the  time  this  study  was  made  some  subsystem  requirements  were  relatively 
firm,  while  others  were  in  the  development  stage,  so  both  methods  were  used 
for  estimating  memory  requirements  for  the  CITS  program. 

5. 3. 2. 2.1  Program  Execution  Module 

5. 3. 2. 2. 1.1  Service  Routines.  Service  modules  consist  of  such  routines  as 
the  Executive,  Input/Output,  Message  Assemblers,  Status  Testing,  and  Computer 
Self-Test.  All  functions  and  routines  except  the  individual  subsystem  testing 
and  utilities  are  included  in  this  category. 

In  estimating  the  size,  each  module  was  considered  separately.  The 
various  functions  were  enumerated.  Sample  block  diagram  flow  charts  were 
used  to  determine  typical  processes  to  be  executed,  and  the  average  number 
of  instructions  determined  for  each  process.  These  were  then  multiplied  by 
the  estimated  usage.  In  the  absence  of  firm  requirements  for  some  methods, 
the  usage  was  determined  from  an  examination  of  the  functions  to  be  performed. 
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the  data  to  be  processed,  the  required  displays,  and  data  to  be  recorded. 

The  storage  estimates  were  summed  for  each  subprogram  module,  and  the  esti¬ 
mate  for  the  service  routines  was  determined  by  summing  each  of  these  modules. 
The  number  of  instructions  required  for  each  of  the  identified  processes  was 
determined  from  the  instruction  set  for  a  typical  general-purpose  computer 
that  could  be  used  for  a  CITS-type  application. 

Typical  processes  considered  in  the  study,  together  with  the  estimated 
number  of  words  required  for  each,  included  the  following: 


Subroutine  calling  sequences  - - -  --  4  words 

Calling  function -  2  words 

Parameters -  2  words 

Discrete  or  flag  testing - 4  words 

Acquisition - 1  word 

Masking  or  unpacking  -  1  word 

Branching -  1  word 

Testing -  1  word 

Discrete  or  flag  setting - 4  words 

Acquisition -  1  word 

Mask -  1  word 

Updating - 1  word 

Storing - 1  word 

Data  block  initialization  -  8  words 

Loop  or  value  initialization  -  3  words 

Storage -  2  words 

Loop  and  branch  control  -  3  words 

Setting  multiple  flags  or  discretes  -  10  words 

Setting  one  discrete  or  flag  -  4  words 

Multiply  by  average  number - (2.5) 

Testing  Multiple  Flags  or  Discretes  -  10  words 

Testing  one  discrete  or  flag  -  4  words 


5-82 


Multiply  by  average  number 
Test  or  function  initialization 


(2.5) 


20  words 


1 


Multiple  flag  setting  -  10  words 

Miscellaneous  housekeeping 

(e.g.,  pointer  control,  address 

and  parameter  conditioning,  etc.) — 10  words 

Test  or  function  calling -  10  words 

Calling -  2  words 

Input  parameters - 4  words 

Output  parameters  - 4  words 


5. 3. 2. 2. 1.2  Subsystem  Test  Routines.  The  primary  purpose  of  the  subsystem 
test  routines  is  to  evaluate  the  state  of  the  subsystem  signals,  and,  in  case 
of  a  failure,  send  a  signal  to  the  service  modules  for  processing. 

When  making  the  sizing  analysis  for  the  CITS  program  the  following  meth¬ 
ods  were  used.  In  subsystem  tests  where  test  flow  diagrams  were  available, 
the  flow  diagram  information  was  used  to  determine  the  processes  needed  to 
implement  each  operation,  and  the  number  of  instructions  required  to  execute 
each  process.  It  was  assumed  that  constants,  such  as  limits,  were  stored  in 
the  data  area.  Typical  processes  used  in  these  signal  tests  were  upper  and 
lower  level  checks,  one  limit  check,  and  discrete  checks.  Figure  5-15  and 
5-16  illustrate  typical  flow  diagrams  for  making  these  tests. 

In  subsystems  where  sufficient  detailed  information  was  unavailable,  the 
data  from  the  parameter  list  was  used  to  estimate  processes  necessary  for  each 
mode/test.  In  this  case  the  following  lumped  estimates  were  made: 


For  each  discrete  check  . .  4  words 

For  each  analog,  digital  check . .  6  words 

For  each  processing  .  10  words 


Some  preprocessing  of  data  was  required  for  signals  packed  in  an  input 
word,  so  additional  instructions  were  included  for  these  cases. 
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UPPER/LOWER  LIMIT  CHECK 


Figure  5-15 
5-84 
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Many  discretes  could  be  checked  simultaneously  and  more  efficiently  if 
those  discretes  relating  to  the  same  subsystem  and  requiring  the  same  type  of 
test  were  packed  in  the  same  input  words.  The  memory  requirements  could  then 
be  adjusted  depending  on  the  percentage  of  such  occurrences.  However,  some 
additional  instruction  might  be  required  to  differentiate  between  individual 
signal  failures.  In  the  case  of  the  B-l  CITS  it  was  assumed  that  these  con¬ 
ditions  were  exceptions  due  to  the  undefined  nature  of  many  of  the  subsystem 
requirements  at  the  time  the  discrete  assignments  were  made.  Common  sub¬ 
routines  were  not  used  because  it  would  be  necessary  to  include  instructions 
to  branch  out  to  the  location  of  the  common  routine  and  where  to  re-enter 
after  completion  of  the  test;  to  load  test  criteria,  such  as  limits  and 
tolerances,  for  different  groups  of  tests;  flag  bit  position  or  location 
where  masks  were  stored;  and  store  re-entrant  points  when  there  are  more 
than  one  exit  from  the  routine.  The  routine  would  have  to  be  longer  in 
words  than  the  number  of  words  to  control  branch-out  operations  to  effec¬ 
tively  save  memory  locations. 

Where  there  were  known  or  assumed  commonalities  and  parallels,  the 
memory  requirements  were  adjusted  to  reflect  this.  This  can  happen  when 
ground  ready  and  performance  monitoring  tests  or  fault  isolation  air  and 
ground  have  tests  in  common. 

The  total  memory  requirements  were  estimated  the  same  way  as  in  the 
service  modules  by  summing  the  memory  requirements  for  each  subsystem  test. 

5. 3. 2. 2. 1.3  Utilities  and  Subroutines.  The  utilities  and  subroutines  used 
by  the  CITS  program  included:  Binary  to  ASCII  conversion,  ASCII  to  binary 
conversion,  I/O  processor,  load  bits,  and  some  mathematical  functions  such 
as  square  root,  etc.  The  storage  requirements  necessary  for  these  routines 
were  estimated  based  on  existing  programs  for  similar  type  computers  exe¬ 
cuting  similar  functions. 
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5. 3. 2. 2. 2  Data  and  Working  Storage  Area 


5. 3. 2. 2. 2.1  Machine  Reserved  Area.  The  low  numbered  memory  area  assigned 
by  computer  hardware  design  for  special  functions  such  as  interrupts,  con¬ 
trol  words,  initialization,  etc.,  is  not  available  as  a  storage  area  for 
general  program  use.  The  number  of  words  required  by  the  CITS  program  was 
determined  from  the  computer  documentation. 

5. 3. 2. 2. 2. 2  Data  Storage.  This  area  is  defined  as  storage  for  subsystem 
and  LRU  status,  past  and  present,  CITS  conditions,  mode,  time  slot,  and 
flag  information;  also,  single  and  double  limits  for  parameter  tests,  masks 
for  discrete  tests  and  flag  settings,  mathematical  constants,  etc. 

For  the  CITS  program  the  memory  space  required  for  this  type  of  in¬ 
formation  was  derived  from  the  subsystem  test  requirements  which  define  the 
number  and  type  of  parameters  processed,  and  the  number  of  flags  and  indi¬ 
cators  for  display  and  recording  information.  Mathematical  constants  were 
estimated  from  computational  requirements  in  the  various  subprogram  modules. 

5. 3. 2. 2. 2. 3  Input/Output  Data  Area.  This  area  was  reserved  for  storage  for 
input/output  related  constants  such  as  fixed  groups  of  addresses,  control 
words,  and  codes  for  each  parameter.  The  amount  of  memory  required  for  this 
type  of  data  was  determined  from  the  input/output  data  requirements. 

5. 3. 2. 2. 2. 4  Data  Buffers.  Temporary  storage  area  was  required  for  data  to 
be  printed,  recorded,  displayed,  and  for  I/O  operations.  This  buffering  was 
necessary  to  coordinate  the  timing  of  the  various  devices.  The  amount  of 
storage  required  for  this  function  was  computed  from  analyzing  the  recording 
requirements  of  the  program  taking  into  consideration  the  timing  constraints 
of  the  various  devices  and  the  frequency  of  transmission  of  the  data. 
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5. 3. 2. 2. 2. 5  Working  Storage.  A  small  scratch  pad  area  was  included  for 
intermediate  computations  and  temporary  storage.  The  amount  of  required 
space  was  estimated  from  the  computational  requirements  of  the  program. 

5. 3. 2.2. 3  Growth  Area 

A  percentage  (25  percent)  of  the  memory  capacity  was  reserved  to  compen¬ 
sate  for  inaccuracies  in  preliminary  analyses  and  for  future  changes.  The 
amount  varied  as  the  program  requirements  became  finalized. 

5. 3. 2. 3  Conclusions 

The  sizing  method  discussed  in  this  section  is  based  on  the  CITS  com¬ 
puter  memory  sizing  analysis  made  early  in  the  B-l  program,  and  was  used  for 
evaluating  CITS  computer  memory  requirements.  The  initial  study  was  based 
on  requirements  that  were  not  completely  definitized.  As  the  requirements 
became  firmer,  and  as  new  tests  were  introduced,  updated  versions  of  this 
document  were  issued. 

From  the  experience  gained  from  the  study  it  was  determined  that  the 
degree  of  accuracy  o'"  the  estimate  varies  with  the  degree  of  finalization 
of  the  program  requirements.  However,  it  was  determined  that  the  25  percent 
growth  area  was  not  adequate  to  cover  the  undefined  portions  and  the  in¬ 
creased  or  revised  requirements  generated  during  the  development  of  the 
program.  A  more  realistic  allowance  would  be  100  percent.  This  was  demon¬ 
strated  during  the  development  of  the  B-l  CITS,  where  memory  requirements 
increased  from  an  original  estimate  of  23,081  halfwords  to  a  final  program 
size  for  A/C-4  of  51,306  halfwords,  necessitating  an  increase  in  the  size  of 
the  computer  memory.  However,  this  method  can  be  used  early  in  a  project  for 
a  gross  initial  estimate  of  the  memory  size  required  to  perform  the  functions 
desired  in  the  program. 
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5.4  LABORATORY  TESTING  AND  VERIFICATION 


The  following  discusses  real-time  software  testing  of  the  onboard  test 
system  and  associated  activities  as  they  should  occur  during  the  development 
process.  Noted  is  the  fact  that  a  well  planned  test  program  starts  at  the 
requirement  generation  stage  and  continues  through  acceptance  testing.  It 
describes  the  activities  and  responsibilities  of  the  test  group  and  discusses 
their  interaction  with  other  groups.  Three  levels  of  testing  are  discussed. 

5.4.1  UNIT  TESTING 

In  general,  the  first  level  of  testing  is  performed  by  people  who  have 
developed  the  software  and  may  be  called  "unit  testing."  The  intention  here 
is  to  determine  that  the  design  has  been  implemented  correctly,  as  compared 
to  the  software  requirements,  and  that  limit  checking,  logical  operation, 
etc. ,  have  been  tested.  This  level  of  testing  includes  the  usual  programmer 
debugging  and  stand-alone  testing.  Its  intention  is  to  give  confidence  that 
the  software  is  ready  for  the  next  level  of  testing. 

5.4.2  INTEGRATION  TESTING 

The  second  or  intermediate  level  of  testing,  integration  testing,  con¬ 
sists  of  integrating  the  individual  software  modules  to  form  a  complete  system 
which  accepts  input  data,  produces  output  data  and  appears  to  operate  properly. 
The  goal  of  integration  testing  is  to  provide  those  who  are  going  to  perform 
the  third  level  of  testing,  software  that  functions  and  will  cycle  when  formal 
testing  is  initiated. 

5.4.3.  VALIDATION  TESTING 

The  third  level  of  testing,  validation  testing,  is  intended  to  prove  that 
the  performance  requirements  are  satisfied  as  expressed  in  the  requirements 
specification  and  that  the  integrated  real-time  program  really  does  meet 
system  level  demands.  This  level  of  testing  may  be  most  effectively  performed 
by  an  independent  testing  group.  Acceptance  testing,  undertaken  to  demonstrate 
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that  the  real-time  software  meets  the  customer's  requirements,  is  at  the  same 
level  as  validation  testing. 

Test  activities  should  begin  with  test  requirements  generation  to  allow 
the  testing  group  to  work  in  parallel  with  the  requirements  group.  This 
eliminated  ambiguous  requirements  since  the  test  group  can  review  them  before 
they  are  finalized  to  determine  that  they  can  conceive  of  a  test  to  demon¬ 
strate  compliance  with  each  requirement.  An  early  start  for  the  test  group 
will  also  enable  the  generation  of  requirements  for  a  "test  driver",  i.e., 
combination  of  hardware  and  software  which  will  test  the  operational  program. 
This  is  not  a  trivial  undertaking  if  testing  a  real-time  program  is  re¬ 
active,  closed- loop  mode. 

A  test  plan  should  be  generated  early  in  the  program  to  form  a  solid 
base  for  future  activities.  The  test  plan  should  contain  the  purpose,  goals, 
and  an  overall  description  of  the  testing  that  is  to  be  performed.  The  test 
plans  may  be  reviewed  and  approved  at  Preliminary  Design  Review  (PDR) . 

5.4.4  CITS  TESTING  APPROACH  AND  EVALUATION 

The  following  is  an  overview  of  the  CITS  engineering  programming  support 
.--/stem  including  an  evaluation  and  recommendation. 

5. 4. 4.1  Support  Hardware  Description 

5. 4. 4. 1.1  AP-2  Computer  Tester 

The  AP-2  Computer  Tester  consists  of  a  Common  Computer  Support  Equipment 
(CCSE),  a  Computer  holding  fixture,  a  power  and  cooling  unit.  All  units  are 
mounted  on  a  table  console.  The  CCSE  is  the  Conputer  controlling  unit  with 
provisions  for  displaying  and  loading  conputer  memory  and  registers. 

5. 4. 4. 1.2  Test  Adapter  Controller  (TAC) 

The  TAC  consists  of  a  SP-1  Conputer,  a  CCSE  which  serves  the  same  purpose 
for  the  SP-1  as  the  CCSE  does  for  the  AP-2,  and  an  Input/output  Unit  (IOU) .  The 
ICU  interfaces  the  SP-1  Computer  to  the  CITS  data  bus  and  the  SP-1  to  the 
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mag  tape,  line  printer,  and  keyboard  display  peripherals.  The  IQU  interface 
with  the  CITS  data  bus  by  means  of  a  standard  CITS  Interface  Unit  (I/U)  which 
is  common  to  the  CITS  Air  Vehicle  configuration.  The  primary  functions  of  the 
TAC  are  to  allow  near  real-time  checkout  and  control  of  the  CITS  Computer 
program  and  control  the  STE-6511. 

5. 4. 4. 1.3  Data  Acquisition  Interface  Test  Unit  (STE-6511) 

The  STE-6511  provides  the  equivalent  Air  Vehicle  discrete,  analog  and 
digital  interfaces  to  the  DAU's.  Signals  at  this  interface  are  controlled 
and/or  changed  by  the  TAC  programming  of  the  STE-6511.  The  TAC  drives  the 
STE-6511  programming  data  by  reading  test  case  records  from  a  test  Data  Base 
Tape.  Tie  STE-6511  consists  of  two  racks  holding  five  signal  coupler  panels, 
which  provide  the  electrical  and  physical  interface  for  Data  Acquisition 
Units  (DAU's),  Airborne  Printer  (A/P),  and  CITS  Control  5  Display  (CCD). 

5. 4. 4. 1.4  Digital  Voltmeter 

The  digital  voltmeter  is  used  basically  for  verifying  DC  voltages  out 
of  the  STE-6511  and  the  CITS  DAU's. 

5. 4. 4. 2  Support  Software  Functional  Description 

5. 4. 4. 2.1  STE  6510  Debug  Simulation  Program  (DSP) 

The  DSP  is  used  to  provide: 

1.  Operator  interface  with  the  CITS  operational  flight  program  (OFP) 
for  test  and  debugging. 

2.  Functional  Simulation  of  peripherals  interfacing  with  the  CITS  Com¬ 
puter  on  board  the  aircraft. 

3.  Loading  of  the  STE-6511  with  the  required  data  values  required  for 
testing  of  the  CITS  operational  program. 

The  functional  interfaces  of  the  DSP  and  the  support  hardware  are  shown 
in  Figure  5-17. 
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DSP/Support  Hardware  Functional  Interface 


The  DSP  provides  the  primary  control/response  functions  of  the  TAC.  The 
DSP  consists  of  the  following  functions. 

Power-Up/ Initialization.  The  DSP,  upon  application  of  power  to  the  TAC 
and/or  reset  of  the  SP-1,  starts  execution  at  a  predefined  location.  The 
initialization  routine  resets  both  IOUs,  load  the  IOU  RAMs,  which  control 
the  direct  peripheral  simulation  modes,  clear  the  display  terminal,  clear 
all  internal  control  flags,  reset  the  AP-2  via  the  AP-2  CCSE,  perform  an 
initial  SP-2  self-test  and  pass  control  to  the  executive  provided  the 
self- test  passed. 

Executive.  The  Executive  executes  in  a  closed- loop  mode.  It  determines 
the  function  to  be  performed  per  a  predefined  order  and  executes  that  function. 
Upon  completion  of  all  functions,  the  executive  returns  to  its  starting  point. 
Functions  to  be  performed  are  either  fixed  or  variable  functions  performed  as 
required.  The  fixed  functions  are  execution  of  the  SP-1  self- test  and  a 
call  to  the  CITS  Airborne  Printer  (A/P)  simulator.  This  self- test  differs  from 
the  initial  self-test  in  that  the  core-sum  routine  sums  250  words  at  each 
pass  rather  than  the  entire  check  sum  area  and  also  that  the  program  is  not 
halted  at  the  detection  of  an  error.  The  error  is  flagged  to  the  operator 
via  a  display  on  the  TAC  CCSE.  The  A/P  simulator  will  execute  provided  dis¬ 
crete  switch  3  is  set,  the  Line  Printer  is  available  and  ready,  and  the  A/P 
simulation  is  enabled.  If  any  of  these  conditions  are  not  met,  the  A/P 
simulator  will  set  printer  busy  in  the  appropriate  status  register  word  in 
the  SP-1  for  eventual  transmission  to  the  AP-2. 

The  variable  functions  are  executed  depending  on  the  desired  mode,  CITS 
control  and  display  (CCD)  simulation  or  DSP  operation.  Discrete  switch  7 
selects  the  mode,  with  the  CCD  simulation  mode  enabled  by  setting  the  switch 
(up  position) . 
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The  DSP  also  provides  automatic  functions  not  directly  selected  by  the 
operator.  Included  in  this  category  is  the  Avionics  Control  Unit  (ACU) 
simulation. 

CCD  Simulator.  The  CCD  simulator  is  executed  whenever  discrete  switch 
7  is  set.  The  DSP  functions  are  overridden  when  in  this  mode  because  the  entire 
LSI  7700  display  is  used  for  this  mode  and  the  keyboard  is  locked  out  to  pre¬ 
vent  operator  interference  with  the  display. 

General  operation  of  the  CCD  simulator  consists  of  display  of  the  CCD 
input  data  in  a  format  similar  to  the  actual  CCD  and  processing  of  operator 
requests.  The  entire  display  is  written  out  at  the  initial  entry  with  changes 
being  displayed  for  subsequent  entries.  The  operator  may  simulate  any  switch 
on  the  CCD  by  depressing  the  INT  key  on  the  keyboard  which  freezes  the 
display  update,  positions  the  cursor  to  the  required  point  on  the  display, 
and  enables  the  keyboard.  Directives  to  simulate  switches  on  the  CCD  always 
begin  with  an  alpha  character  while  CCD  keyboard  entries  are  always  numeric 
(up  to  10  digits) .  The  ECM,  RETURN,  and  SEND  keys  on  the  LSI  7700  are  de¬ 
pressed  in  that  order  to  issue  the  directive  to  the  CCD  simulator  function. 

The  LSI  7700  keyboard  is  then  locked  and  the  directive/data  placed  in  the 
appropriate  output  buffer  for  eventual  transmission  to  the  AP-2.  Timing  and 
interlocks  within  the  CCD  are  simulated  to  as  high  a  degree  as  possible. 

When  discrete  switch  7  is  turned  off,  the  DSP  mode  is  enabled  and  the 
CCD  display  is  cleared,  provided  all  functions  within  the  simulator  are  com¬ 
pleted.  Should  any  function  that  spans  entries  to  the  simulator  (e.g.  entry 
of  directives)  be  incomplete  at  this  time,  CCD  simulation  mode  shall  remain 
in  effect  until  completion  of  the  function.  The  function  in  progress  may  be 
terminated  and  the  DSP  mode  enabled  by  depressing  the  interrupt  (INT)  key  on 
the  LSI  7700  with  discrete  switch  7  down. 
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Avionics  Control  Unit  (ACU)  Simulation.  The  ACU  sinulation  is  completely 
automatic  provided  the  AP-2  is  requesting  communication  with  any  ACU  via  I/O 
channel  2  and  the  specified  ACU(s)  simulation  is  enabled.  The  present  version 
provides  simulation  for  two  ACU's,  the  weapons  delivery  (WD)  and  guidance  and 
navigation  (GN)  ACU's.  The  simulation  technique  is  a  combination  of  TAC  hard¬ 
ware  and  software  and  operates  as  follows: 

a.  Receipt  of  a  predefined  control  word  from  the  AP-2  initiates 
an  interrupt  within  the  DSP,  provided  bits  5  through  10  of  the 
data  field  in  the  received  control  word  match  bits  4  through  14 
of  a  simulator  control  word  in  the  random  access  memory  [RAM) 
associated  with  I/O  channel  2  simulation.  The  specific  word 
within  the  RAM  to  which  the  comparison  is  made  is  determined 

by  the  address  field  in  the  received  control  word. 

b.  Control  is  passed  to  an  interrupt  processor  routine  which 
updates  counters  within  the  data  to  be  transmitted  to  the 
AP-2  via  I/O  channel  2.  The  processor  routine  further  checks 
portions  of  the  last  received  data  and  sets/resets  appropriate 
"handshaking"  control  parameters.  An  example  of  this  is  the 
transfer  of  printer  data  from  the  ACU  simulator  to  the  AP-2. 

A  print  message  request  is  made  by  setting  the  print  request 
word  to  non- zero  value.  This  is  usually  done  by  reading  the 
appropriate  input  data  record  on  the  base  tape. 

When  the  AP-2  operational  program  has  received  the  print 
message,  it  responds  by  returning  a  print  knowledge.  The 
interrupt  processor  routine  will  reset  the  request  upon 
detection  of  the  acknowledge.  The  acknowledge  is  then 
reset  by  the  AP-2  operational  program. 
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c.  The  interrupt  processor  returns  control  to  the  interrupted  point 
at  completion  of  its  function. 

The  TAC  hardware  automatically  processes  I/O  messages  tc  and  from  the 
AP-2  once  a  valid  control  word  is  received.  Received  control  words  are 
checked  to  correct  peripheral  device  address,  transmit/ receive  bit  state, 
and  data  word  count.  If  an  error  is  detected,  the  TAC  resets  for  receipt 
of  the  first  control  word  of  the  message  sequence.  No  further  action  takes 
place  until  receipt  of  word. 

Messages  within  the  sequence  are  either  fixed,  time  scheduled  or  demand 
scheduled.  The  control  word  for  each  message  is  always  transmitted  from  the 
AP-2  regardless  of  the  message  type.  The  TAC  hardware  counts  each  control 
word  and  when  the  count  reaches  a  value  predefined  in  the  RAM  simulator  con¬ 
trol  word,  the  TAC  resets  to  expect  the  first  AP-2  control  word  in  the  mes¬ 
sage  sequence.  Fixed  messages  always  have  one  or  more  data  words  included. 
Time  scheduled  and  demand  scheduled  messages  contain  data  words  only  when 
they  are  scheduled.  Scheduling  is  controlled  by  the  AP-2  operational  program. 
Data  for  scheduled  messages  must  be  available  prior  to  its  transmission.  The 
TAC  does  not  error  check  control  words  with  a  word  count  of  zero,  but  it  does 
update  the  message  counter. 

Fixed  scheduled  messages  typically  contain  status  and  handshaking  infor¬ 
mation  required  to  maintain  synchronous  flow  of  data  between  the  AP-2  and 
ACU(s).  They  may  also  contain  data  required  on  a  continuous  basis.  Time 
scheduled  message  typically  contain  data  required  on  a  periodic  basis.  Some 
examples  are  CCD  messages  and  subsystem  test  data  acquired  by  one  computer 
and  used  by  the  other.  Variable  scheduled  messages  typically  contain  test 
oriented  data  such  as  printer  and  maintenance  recorder  data  or  power  con¬ 
troller  command  blocks. 
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5 . 4 . 4 . 2 . 2  DSP  Funct ions 

The  DSP  functions  are  defined  as  input/output  to  the  TAC  peripherals, 

CITS  peripheral  simulations,  AP-2/TAC  communications,  and  operational  dir¬ 
ective  processing.  The  DSP  functional  interface  is  shown  as  Figure  S-18. 

5. 4. 4. 2. 2.1  TAC  Peripheral  Input/Output.  TAC  peripheral  input/output  (I/O) 
operations  are  handled  by  issuing  specified  commands  to  pheripheral  as  re¬ 
quired  by  the  sequence  of  processing  and  setting  program  flags  to  indicate 
the  I/O  operation  in  progress.  As  each  device  completes  its  specified  oper¬ 
ation,  it  enables  an  interrupt  to  the  SP-1.  The  interrupt  processor  in  turn 
clears  the  I/O  in  progress  and  sets  the  I/O  complete  flag  for  the  device 
being  conmunicated  with.  In  addition,  the  interrupt  processor  will  set  ad¬ 
ditional  or  command  operations  depending  on  the  specific  interrupt.  Some 
examples  of  this  are:  Restarting  the  AP-2  if  it  was  halted  for  a  magnetic 
tape  operation,  enabling  the  keyboard  after  reading  the  data  from  the  dis¬ 
play  terminal,  or  resetting  directive  control  flags  upon  direction  of  a  key¬ 
board  interrupt  in  the  DSP  mode. 

5. 4. 4. 2. 2. 2  CITS  Peripheral  Simulation.  CITS  peripheral  simulation  is  hard¬ 
ware  executed  by  the  TAC  IOU  under  program  control. 

5. 4. 4. 2. 2. 3  AP-2  TAC  Communications.  The  AP-2/TAC  interface  is  via  the  chan¬ 
nel  1  data  bus.  Directives  to  the  AP-2  debug  program,  residing  in  the  AP-2 

as  part  of  the  operational  program,  are  placed  by  the  DSP  in  a  dedicated  buf¬ 
fer  area  in  the  SP-1.  This  buffer  is  transmitted  to  the  AP-2  upon  its  direc¬ 
tion  by  a  control  word  from  the  AP-2  with  a  Device  Address  =  12,  T/R  bit  =  1, 
Mode  Code  other  than  2,  and  a  Word  Count  =  4.  The  AP-2  Debug  will  the  pro¬ 
cess  the  directive  and  respond  with  data  (if  requested)  contained  in  a  mes¬ 
sage  via  channel  1  data  bus  preceded  by  a  control  word  with  a  Device  Address  = 
12,  and  T/R  bit  =  0.  The  mode  code  and  word  count  are  dependent  on  the  type 
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Debug  Simulation  Program  Functional  Interface 
Figure  5-18 


and  quantity  of  data  sent  to  the  TAC.  This  response  data  is  further  pro¬ 
cessed  by  the  DSP  and  displayed  as  required  by  the  operator. 

5. 4. 4. 2. 2. 4  Operator  Directive  Interface.  Operator  directives  are  entered 
into  the  DSP  via  the  TAC  CCSE  discrete  switches  and/or  LSI  7700  display  ter¬ 
minal  keyboard.  Normally,  specific  actions  are  requested  via  the  LSI  7700 
while  DSP  operating  modes  are  selected  via  the  CCSE  discrete  switches. 

5. 4. 4. 2. 2. 5  Operator  Directive  Processing.  The  DSP  processes  operated-en- 
tered  directives  via  a  command  decode  (CMDC)  subroutine  and  subordinate  com¬ 
mand  subroutines  (CSR).  The  entered  data  is  validity  checked  by  CMDC,  and 
if  it  is  valid,  sets  the  operation  in  progress  flag  and  branches  to  the  ap¬ 
propriate  CSR.  There  is  one  CSR  for  each  directive  available.  CSR's  are 
one  of  two  types,  single  pass  and  multiple  pass.  Single  pass  CSR's  will 
complete  their  function  and  pass  control  to  the  executive.  Miltiple  pass 
CSR's  will  perform  a  specific  action,  initiate  I/O  with  a  TAC  peripheral, 
and  pass  control  to  the  executive.  Prior  to  doing  so,  the  CSR  is  required 
to  set  up  the  linkage  addresses  required  to  resume  control  after  completion 
of  requested  I/O.  The  executive  will  pass  control  to  the  CSR  upon  success¬ 
ful  completion  of  I/O.  Upon  completion  of  the  CSR's  function,  control  is 
permanently  relinquished  to  the  executive  by  issuing  a  message  to  the  I/O 

so  the  display  will  reset  the  command  in  progress  flag,  preventing  the  ex- 
exutive  from  passing  control  to  any  CSR.  The  DSP  is  structured  to  prevent 
more  than  one  CSR  fn'r.i  being  active  at  a  time. 

5.4. 4. 2. 3  Data  Base  Processing 

The  DSP  provides  a  test  data  base  interface  to  the  AP-2  operational  pro¬ 
gram  for  use  in  debugging  and  qualification  of  the  operational  program.  This 
function,  hereinafter  referred  to  as  the  data  bus  driver  (DBD),  is  currently 
executed  as  a  directive  to  the  DSP.  The  DBD  requires,  as  input,  data  residing 
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on  a  magnetic  tape.  This  data  is  processed  by  the  update  I/O  simulation 
tables  (UPIOS)  subroutine.  Outputs  are  selectable  by  the  operator  and  are 
routed  either  to  the  AP-2  directly  via  the  simulation  features  of  the  TAC 
or  to  the  STE-6511. 

5. 4. 4. 2. 3.1  CITS  Data  Base  Load  Tape.  The  CITS  Data  Base  Load  Tape  is  used 
to  supply  the  simulated  aircraft  and  avionics  signals  required  by  the  Debug 
Simulation  Program  to  support  the  STE-6510  and  STE-6511. 

5. 4. 4. 2. 3. 2  Data  Base  Tape  Format.  The  data  residing  on  the  input  data  base 
tape  consists  of  physical  records  blocked  into  logical  records.  Logical  re¬ 
cords  consist  of  four  tapes,  identification,  data  bus  1  data,  data  bus  2  data, 
and  control.  The  identification  record  is  2  bytes  (16  bits)  in  length  and 
serves  to  identify  the  physical  record.  It  is  always  first  in  the  physical 
record.  The  remaining  types  follow  are  each  8  bytes  (64  bits)  in  length. 

For  convenience,  they  are  further  broken  down  into  2 -byte  words  (4  words  per 
record) .  The  maximum  number  of  logical  records  per  physical  record  is  130 
or  1,034  bytes. 

5.4.4. 2.4  Capabilities/Limitations 

5. 4. 4. 2. 4.1  Capabilities .  Simulation  of  all  aircraft  signals  in  a  static 
operational  mode. 

0  Simulation  of  some  CITS  peripherals  allowing  testing  with  partial 
CITS. 

0  Monitoring  of  CITS  discrete  and  analog  channels  is  possible,  external 
to  the  CITS  Operational  Program. 

°  Simulation  of  the  ACUC  is  provided  in  a  static  mode. 

°  Monitoring  of  CITS  Data  Bases  traffic  is  provided  for  periodic  Input/ 
Output  data. 
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0  Operator  interface  and  controls  are  provided  to  allow  problem  investi¬ 
gation  to  a  detailed  level. 

°  Hard  copy  of  selected  test  results  and  diagnostic  data  is  provided. 

°  Ability  to  load  and  dump  load  tapes  and  executed  programs  rapidly  via 
magnetic  tape. 

°  Modification  of  loaded  Operational  Program  is  easily  facilitated  as 
well  as  fabrication  of  new  load  tapes. 

0  CITS  system  level  testing  is  available  in  a  static  mode  if  all  CITS 
peripherals  are  provided. 

0  Real-time  operator  interface  with  the  CCD  is  provided. 

5. 4. 4. 2. 4. 2  Limitations.  The  present  laboratory  support  software  mechani¬ 
zation  is  limited  in  these  areas: 

°  Dynamic  simulation  is  extremely  limited. 

0  DAU's  number  1,  number  2,  and  number  S  cannot  be  properly  simulated. 

°  Response  to  CITS  output  stimuli  cannot  be  simulated. 

°  Monitoring  of  transient  data  on  the  CITS  data  buses  is  not  available. 

°  Diagnostic  programs  for  the  support  hardware  (with  the  exception  of 
the  SP  1  computer  in  the  TAC)  are  not  presently  available. 

°  Functional  test  programs  for  the  CITS  peripherals  require  modification 
to  run  on  the  support  hardware. 

0  Dynamic  simulation  of  the  ACUC  is  not  presently  available. 

0  Dynamic  testing  of  the  CITS  system  level  is  extremely  limited. 

°  Transfer  of  aircraft  recorded  diagnostic  data  to  the  CITS  test  data 
base  for  problem  investigation  is  extremely  difficult. 

0  Loading  of  the  CITS  Test  Data  Base  for  test  runs  is  a  long  and  tedious 
process,  requiring  many  operator  actions. 

5.  S  LANGUAGL  SELECTION 

The  use  of  a  common  language  for  all  onboard  software  can  have  some  ad¬ 
vantages.  For  example,  only  one  set  of  support  software  would  be  required, 
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therefore  minimizing  the  development  and/or  maintenance  costs;  personnel  need 
be  trained  in  only  one  programing  language;  and  any  interaction  between  pro¬ 
grams  is  facilitated.  On  the  other  hand,  there  can  be  some  disadvantages. 

The  suitability  of  the  language  might  be  compromised,  as  desired  language 
features  can  vary  from  one  type  of  software  to  another,  leaving  some  programs 
inefficient  in  timing  and/or  memory  utilization.  Enforcement  of  software 
standardization,  MIL-STD-1589B  and  MIL-STD-1750A,  will  result  in  the  use  of 
JOVIAL  (J73)  for  all  software,  unless  it  can  be  demonstrated  that  the  program 
will  be  so  inefficient  it  will  not  meet  the  operating  requirements  or  that  the 
development  costs  would  be  too  high  to  warrant  using  the  standardized  language. 

In  choosing  a  programming  language  for  an  onboard,  real-time  test  system 
several  factors  must  be  considered.  These  can  be  grouped  into  five  major  cat¬ 
egories  : 

1.  Suitability 

2.  Availability 

3.  Transferability 

4.  Supportability 

5.  Maintainability 

Of  the  five,  suitability,  of  course,  is  the  most  important.  Most  general 
purpose  languages  could  be  used;  however,  the  resulting  program  may  be  very 
costly  in  memory  utilization  and/or  execution  time.  These  five  factors  must 
be  weighed  according  to  the  individual  requirements,  schedule,  and  cost. 

The  advent  of  standardization,  Military  Standard  JOVIAL  (J73)  (MIL-STD- 
1589B)  and  Military  Standard  Sixteen-Bit  Computer  Instruction  Set  Architecture 
(MIL-STD-1750A) ,  will  eliminate  or  change  the  importance  of  the  above  factors. 
Transferability,  supportability,  and  maintainability  would  automatically  fol¬ 
low;  therefore  suitability  and  availability  are  the  major  factors. 

In  considering  the  suitability  of  a  language  for  a  CITS-type  application 
program  the  features  of  the  language  must  be  evaluated  to  determine  if  they 
adequately  support  those  required  by  the  program. 
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In  addition,  when  evaluating  a  higher  order  language  the  compiler  must 
be  considered  as  well  as  the  language.  There  must  be  a  compiler  available 
for  the  target  computer  that  will  produce  efficient  code  which  will  meet  size 
and  timing  requirements,  and  that  will  produce  a  program  that  is  easy  to  under¬ 
stand  and  modify.  Additional  considerations  are  discussed  in  paragraph  5. 5. 1.1. 
Availability  is  also  an  important  factor  in  the  selection,  as  the  use  of  a  new 
and  relatively  untried  compiler  will  introduce  a  risk  which  could  affect  the 
cost  and  schedule  for  producing  the  software.  This  is  discussed  in  paragraph 
5. 5. 1.2. 

After  careful  consideration  it  may  prove  to  be  cost  effective  to  use  a 
language  other  than  that  designated  for  the  standard.  If  so,  the  points  enum¬ 
erated  in  the  following  sections  may  be  used  in  the  evaluation  and  selection 
of  a  substitute  programming  language. 

5.5.1  CONSIDERATIONS  IN  EVALUATING  A  LANGUAGE 

5. 5.1.1  Suitability 

In  evaluating  the  suitability  of  a  programming  language  for  an  onboard 
test  system  a  number  of  factors  should  be  considered.  The  following,  as  a 
minimum,  should  be  used  in  this  evaluation: 

1.  Available  features  -  the  language  should  adequately  support  the 
features  required  by  the  application  program.  The  following  ques¬ 
tions  should  be  considered  in  the  evaluation: 

A.  What  features  does  the  language  have  that  permit  it  to  take 
advantage  of  particular  target  machine  features  and  idio- 
syncrancies? 

B.  How  much  control  does  the  programmer  have  regarding  register 
assignment,  memory  locations,  and  machine  instructions? 

C.  How  does  it  handle  switches,  indicators,  arbitrary  bit  patterns? 
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D.  What  facilities  does  it  have  to  describe  and  utilize  various 
kinds  of  data? 

E.  How  easy  is  it  to  access  and  manipulate  bits  and  bytes? 

F.  How  does  it  handle  fixed-point  numbers,  accuracy,  and  pre¬ 
cision?  Is  scaling  under  program  mer  control,  or  do  all  scaling 
decisions  depend  on  the  programing  and  data  declarations? 

2.  Flexibility  -  the  language  should  efficiently  handle  subroutines,  their 
call  and  return.  There  should  be  allowance  for  the  incorporation  of 
machine  or  other  languages  if  necessary. 

3.  Modularity  -  the  language  should  be  adaptable  to  the  concepts  of 
structured  programming,  modularity,  and  top-down  or  bottom-up  design. 

It  should  be  capable  of  compilation  of  individual  modules. 

4.  Efficient  code  -  the  compiler  should  produce  efficient  code  for  the 
target  computer. 

5.  Compiler  efficiency  -  the  compiler  should  operate  in  an  efficient 
manner.  Recompilation  should  not  be  a  long  and  expensive  operation. 

6.  Debug  capabilities  -  the  language  and  compiler  should  support  debug 
and  validation  to  the  degree  necessary  to  produce  a  correct  program. 

7.  Readability  -  the  program  written  in  the  language  should  be  easy  to 
read  and  understand.  This  is  related  to  item  8. 

8.  Documentation  -  the  language  should  be  self- documenting.  Enough  in¬ 
formation  should  be  produced  during  compilation  to  provide  the  nec¬ 
essary  visibility  and/or  information  to  readily  understand  and  eval¬ 
uate  the  program. 

9.  Programmer  familiarity  -  to  produce  an  efficient  and  well  designed 
program,  programmers  familiar  with  the  language  are  an  asset.  If  not 
available,  the  degree  of  training  required,  the  existing  training  aids, 
and  the  time  needed  to  reach  the  desired  familiarity  must  be  considered. 

5. 5. 1.2  Availability 

If  ready-made  software  suits  the  application,  it  may  be  the  best  choice. 
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even  though  it  does  not  meet  all  the  criteria.  Schedules  and  cost  may  dictate 
the  use  of  some  established  and  dependable  language  over  one  still  in  develop¬ 
ment,  or  to  be  developed.  Also,  a  risk  is  involved  in  the  use  of  a  new  and 
untried  compiler  for  an  established  language.  A  new  compiler,  for  example, 
will  require  time  to  develop  and  validate.  Usage,  along,  will  give  the  degree 
of  confidence  desired  to  support  program  development. 

There  is  a  disadvantage,  however,  in  the  choice  of  some  available  lan¬ 
guages,  in  particular  assembly  language.  It  may  commit  the  user  to  one  hard¬ 
ware  supplier  and  limit  the  choice  to  languages  supported  by  that  system. 

5.5.1. 3  Transferability 

In  considering  the  language  selection  for  a  program  that  may  have  a  life¬ 
time  of  several  years,  a  major  consideration  would  be  the  transferability  to 
a  new  and  more  advanced  environment.  Theoretically,  when  using  a  higher  order 
language  the  change  in  computer  should  have  no  impact  on  the  software.  However, 
in  practice  this  is  seldom  the  case.  The  following  factors  can  affect  the 
transferability  of  the  application  software: 

1.  The  amount  of  machine  language  that  has  been  inserted  into  the  pro¬ 
gram  in  various  places  to  increase  the  efficiency  of  the  program. 

These  sequences  would  require  recoding. 

2.  The  availability  of  a  new  compiler  for  the  new  hardware.  Does  it 
need  to  be  developed,  or,  if  in  existence,  how  well  is  it  checked  oqt? 

3.  Incompatibilities  that  may  exist  between  the  old  system  and  the  new 
that  requires  program  modification. 

V. 

4.  The  risk  of  incorporating  subtle,  hard-to-find  errors  wfcen  converting 
to  a  new  system. 

Language  and  instruction  set  standardization  should  eliminate  the  above 
problems . 
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5. 5. 1.4  Supportability 

Things  to  be  considered  under  this  category  are: 

1.  The  language  should  be  broad  enough  in  scope  to  be  useful  for  a  var¬ 
iety  of  applications  and,  therefore,  well  supported  throughout  the 
life  cycle  of  the  program. 

2.  There  are  enough  users  to  assure  that  the  language,  itself,  will  not 
become  obsolete. 

3.  The  language  is  standardized  to  the  extent  that  it  will  continue  to 
be  valid  and  supported  when  new  systems  are  developed. 

4.  The  proliferation  of  subsets  to  the  language  will  not  cause  the  spec¬ 
ific  version  to  become  obsolete  and  support  activity  discontinued. 

5.  Language  subsets  may  be  dedicated  to  particular  systems  and  not  easily 
modified  when  the  system  changes. 

Adherence  to  MIL-STD-1750A  and  MIL-STD-1589B  would  result  in  sufficient 
usage  to  assure  the  continued  support  of  the  language. 

5. 5.1.5  Maintainability 

Since  program  maintenance  is  often  the  largest  cost  factor,  it  is  impor¬ 
tant  that  careful  consideration  be  given  to  the  selection  of  the  language. 
Program  maintenance  can  roughly  be  divided  into  two  types: 

1.  In-field  debugging  of  errors  that  escaped  the  validation  effort. 

2.  Enhancements  and  modifications  to  the  program  due  to  a  variety  of 
causes. 

As  maintenance  is  usually  done  by  personnel  other  than  those  responsible 
for  the  program  development  good  documentation  is  a  must.  This  includes  com¬ 
puter  generated  aids  such  as  cross -reference  lists,  set/used  lists  and  load 
maps  as  well  as  the  requirements  and  design  documents.  The  features  listed 
under  Suitability  that  are  most  important  for  this  phase  of  the  program  life 
cycle  are: 
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1 .  Modularity 

2.  Compiler  efficiencv 

3.  Debug  capabilities 

4.  Readability 

5.  Documentation  aids 

In  the  case  of  standardization,  these  properties  would  probably  be  in¬ 
corporated,  so  they  need  not  be  a  major  factor  in  the  evaluation  of  the  lan¬ 
guage. 

5.5.2  CITS  LANGUAGE  SELECTION 

Analysis  of  results  obtained  from  a  B-l  common  language  study  (NA-71-605), 
made  early  in  the  program  led  to  a  recommendation  that  JOVIAL,  with  the  mod¬ 
ifications  discussed  at  that  time  in  the  report,  be  adopted  as  the  "B-l  Common 
Language."  Several  features  of  JOVIAL  made  it  attractive  for  a  test  system, 
real-time  computer  program;  namely,  the  COMPOOL  concept  for  data  management, 
the  packing/unpacking  capability,  and  the  ability  to  manipulate  bits  and  bytes 
At  that  time  the  JOVIAL  language  was  undergoing  upgrading  and  modification, 
and  the  new  version,  JOVIAL  (J73) ,  was  the  version  recommended  by  the  study. 

In  order  to  adhere  to  the  B-l  development  schedule,  programming  for  the  CITS 
system  had  to  begin  prior  to  the  release  of  a  JOVIAL  (J73)  compiler.  In  ad¬ 
dition,  a  compiler  producing  code  for  the  designated  CITS  computer  would  need 
to  be  developed.  In  evaluating  the  languages  then  available,  FORTRAN,  PL/1, 
JOVIAL  (J3),  and  assembly  language,  it  was  determined  that  the  assembly  lan¬ 
guage  would  inpact  cost  and  schedule  the  least,  as  the  supporting  software  was 
already  developed  and  the  features  of  the  language  would  give  the  desired  con¬ 
trol  over  computer  operations,  thus  satisfying  the  two  requirements  of  avail¬ 
ability  and  suitability.  In  the  case  of  the  higher-order  languages,  they  not 
only  did  not  adequately  support  the  desired  features,  there  was  no  compiler 
available  for  the  selection  onboard  computer.  Because  of  the  cost,  the  risk 
of  using  an  untried  and  untested  compiler,  and  the  schedule  demands,  it  was 
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determined  that  it  would  be  more  cost  effective  to  utilize  the  AP-2  assembly 
language  for  the  development  of  the  CITS  onboard  test  system  computer  program. 

5.6  SUMARY 

This  section  deals  with  the  total  effort  involved  in  the  development  of 
a  software  program  required  by  an  onboard  test  system,  and  gives  examples  and 
illustrations  of  the  techniques  and  methods  employed  in  the  development  of  the 
B-l  CITS  software  program.  A  complete  description  of  the  CITS  program  is  in¬ 
cluded. 

The  approach  recommended  for  software  development  is  discussed,  whereby 
mandatory  requirements  dictated  by  Air  Force  regulations  are  outlined  first, 
followed  by  criteria  and  techniques  involving  choices.  These  choices  include 
alternate  methods  of  program  organization,  such  as  fixed  rate  straight  line, 
interrupt  control,  and  multi-rate  fixed  cycle;  estimation  techniques  for  time 
phasing  and  for  memory  sizing;  and  factors  to  be  considered  in  the  evaluation 
and  selection  of  a  programming  language.  Advantages  and  disadvantages  are 
given  for  choices  where  applicable,  along  with  the  choices  made  for  the  CITS 
and  the  rationale  for  the  choices. 
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Section  6 


SIGNAL  PROCESSING 


6.0  INTRODUCTION 

In  this  design  guide,  Section  4  discussed  the  signal  processing  aspects  of 
the  onboard  test  system  as  it  affects  the  design  of  the  hardware.  In  this  sec¬ 
tion  the  hardware  techniques  will  be  reviewed,  and  in  addition,  what  signal  proc¬ 
essing  techniques  can  be  utilized  which  use  software  as  the  implementation  tool. 
The  purpose  of  discussing  both  hardware  and  software  techniques  is  to  enlighten 
the  test  system  designer  to  the  fact  that,  depending  on  the  complexity  of  the 
test  system,  both  methods  may  be  required. 

6.1  TYPES  OF  SIGNAL  PROCESSING 

For  this  section  the  signal  processing  discussed  will  be  segregated  by  the 
type  of  signal  processed.  There  are  three  basic  types  of  signals  which  need  to 
be  acquisitioned  by  the  test  system:  1)  Serial  Digital  Signals,  2)  Analog  Sig¬ 
nals,  and  3)  Discrete  Signals. 

6.1.1  SERIAL  DIGITAL 

When  acquiring  serial  digital  data,  there  are  two  primary  sources:  1) 

Analog  data  converted  to  serial  digital  form  and  2)  Test  results  status  discretes 
packed  into  a  digital  word.  There  are  additional  processing  techniques  required 
before  the  serial  digital  data  car  be  utilized  by  the  test  program. 

For  the  first  case  of  analog  data  conversion  to  serial  digital  words,  three 
hardware  implementation  methods  were  discussed  in  Section  4.  The  three  methods 
were  successive  approximation,  integration,  and  the  counter  techniques.  In 
some  cases,  before  serial  digital  data  obtained  by  one  of  the  three  techniques 
can  be  utilized,  further  processing  could  be  required.  Two  basic  techniques 
which  are  used  to  process  serial  digital  data  words  are:  1)  Data  word  reordering 
and  2)  Data  word  scaling  with  respect  to  numeric  value.  Data  word  reordering  is 
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used  when  the  accessed  data  words  are  not  in  an  order  such  that  the  program 
can  utilize  them  to  execute  looping  methods  for  efficient  test  system  program¬ 
ming.  A  program  loop  provides  a  series  of  program  instructions  that  are  exe¬ 
cuted  repeatedly  with  modified  instructions  or  modified  data  values.  A  looping 
function  requires  fewer  program  steps  for  a  series  of  executions  than  would  be 
required  for  individually  describing  and  executing  each  process  or  each  data 
value.  The  data  inputs  operated  upon  by  a  loop  can  be  arranged  in  an  orderly 
manner  to  minimize  programming  steps  and  time  for  access.  In  general,  repet¬ 
itive  processes  are  inherently  more  efficient  due  to  a  reduction  of  the  execut¬ 
able  steps  following  definition  of  the  repetitive  process.  The  reordering  tech¬ 
nique  is  accomplished  by  the  software  input/output  subroutine  acquis itioning  the 
required  test  data  and  storing  the  information  in  a  predetermined  core  memory 
location.  When  the  test  software  module  prepares  for  performance  of  the  test, 
reordering  of  the  data  occurs  before  the  test  is  executed.  The  test  system 
would  have  an  area  in  memory  that  is  used  by  all  test  routines  as  a  scratch 
pad.  For  this  technique  the  test  program  would  use  the  scratch  pad  area  as 
a  temporary  location  to  store  the  reoxdered  data.  The  program  would  individually 
transfer  sixteen  bit  words,  or  blocks  of  words,  to  the  desired  location  in  the 
scratch  pad  area  in  memory.  When  all  the  data  has  been  transferred  the  result¬ 
ant  data  would  be  in  the  proper  order  for  efficient  programming  techniques  to 
be  utilized. 

The  second  processing  technique  is  data  word  scaling.  This  method  involves 
reducing  or  increasing  the  numerical  value  of  the  digital  word  by  means  of  multi¬ 
plying,  dividing,  or  shifting  by  certain  constants  stored  in  memory.  An  example 
of  this  method  can  be  seen  in  the  B-l  engine  CITS  test  program.  In  this  test 
both  engine  instrument  and  engine  mounted  CITS  processor  data  were  utilized. 

The  reason  that  the  scaling  was  used  is  because  the  serial  digital  formats  from 
the  two  sources  were  different.  The  engine  instruments  data  have  to  be  shifted 
one  bit  to  the  left  to  increase  their  value  by  two,  in  order  that  a  calculation 
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could  be  made  using  both  engine  processor  and  engine  instrument  data.  The 
scaling  technique  is  an  excellent  method  when  utilizing  data  where  digital 
format  dissimilarities  exist  and  a  relatively  simple  solution  is  necessary. 

This  method  can  cause  difficulties  because  for  extensive  calculations  involv¬ 
ing  many  parameters,  the  resultant  scaling  of  the  answer  is  sometimes  difficult 
to  determine.  Normally  a  calculation  is  performed  to  determine  what  a  variable 
test  limit  should  be.  In  this  example  when  the  calculated  number  was  determined, 
it  was  rescaled  to  be  compatible  with  the  parameter  to  be  tested,  in  order  that 
a  one-to-one  comparison  could  be  made  by  the  software  program.  Another  method 
of  further  data  processing  related  to  packed  discrete  words  is  the  unpacking 
and  packing  of  the  discretes.  Software  programs,  to  be  efficient,  must  have 
the  capability  of  using  looping  and  common  subroutines.  In  order  for  this  to 
be  implemented  the  discretes  must  be  in  a  specific  repeatable  sequence  for  the 
program  to  use  the  same  portion  of  the  software  program  to  perform  many  tests. 

The  order  of  the  discretes  in  a  packed  discrete  word  is  dependent  on  the  wiring 
of  the  signals  to  the  data  acquisition  device.  When  these  wire  designations 
are  made  considerations  of  both  test  program  configurations  and  wire  routing 
restrictions  are  made.  Due  to  the  signal  density  variations  and  data  acqui¬ 
sition  from  all  types  of  subsystems,  any  one  packed  discrete  may  contain  dis¬ 
cretes  from  several  different  systems  (see  Table  VT -1) .  Another  case  of  mis- 
ordered  packed  discretes  exists  when  a  system  executes  a  series  of  BIT  and 
transmits  the  go/no-go  results  by  means  of  serial  digital  packed  discretes. 

The  source  of  this  type  of  packed  discretes  usually  is  a  controller  with  the 
complexity  and  capabilities  of  a  mini  computer.  An  example  where  the  reordering 
technique  was  used  extensively  was  in  the  B-l  CITS  test  for  the  AICS,  where  the 
source  of  the  packed  discretes  was  a  controller.  The  AICS  controllers,  which 
were  corparable  to  mini  computers,  executed  specific  tests  and  recorded  the 
results  in  the  form  of  packed  discretes.  The  packed  discretes  would  then  be 
accessed  by  the  CITS  DAU,  preprocessed  and  tested.  Greater  than  90  percent  of 
the  data  utilized  for  the  AICS  test  were  packed  discretes.  Before  the  software 
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Table  VI -1 


Typical  Packed  Discrete  Word 


BIT  NO. 

SIGNAL  NOMENCLATURE 

SUBSYSTEM 

1 

Surface  Position  Indicator  Power  On 

Wing  Sweep 

2 

Surface  Position  Indicator  Valid 

Wing  Sweep 

3 

Command  Transducer  Energized 

Landing  Gear 

4 

Follow-Up  Transducer  Energized 

Landing  Gear 

5 

E-H  Value  Shorted/Open 

Landing  Gear 

6 

Fail-Safe  Rate 

Landing  Gear 

7 

Fail-Safe  Output 

Landing  Gear 

8 

Solenoid  Valve  No.  1  Current 

Landing  Gear 

9 

Solenoid  Valve  No.  2  Current 

Landing  Gear 

10 

Taxi -Takeoff  Switch  Position 

Landing  Gear 

11 

Left  Forward  Shutoff  Valve  Closed 

Structural  Mode  Control 

12 

Left  Aft  Shutoff  Valve  Closed 

Structural  Mode  Control 

13 

Right  Forward  Shutoff  Valve  Closed 

Structural  Mode  Control 

14 

Right  Aft  Shutoff  Valve  Closed 

Structural  Mode  Control 

15 

Standby  ADI  Power  On 

Flight  Director  Computer 

16 

Standby  ADI  Valid 

Flight  Director  Computer 
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program  could  efficiently  test  the  acquisition  data,  all  discretes  had  to  be 
separated  and  repacked  into  reserved  memory  locations  in  the  computer.  These 
discussions  and  examples  illustrate  that  in  some  cases  the  acquired  serial 
digital  data  is  not  directly  usable  by  the  test  program  and  require  one  or 
more  of  the  processing  techniques  discussed  to  be  performed  before  testing 
of  the  system  can  be  executed  by  the  onboard  test  system.  The  discrete  re¬ 
ordering  technique  requires  the  program  to  transfer,  bit  by  bit,  each  piece 
of  information  from  the  reserved  input/output  area  to  a  predetermined  loca¬ 
tion  in  the  scratch  pad  location  in  memory.  The  preprocessing  portion  of  the 
program  does  not  employ  looping  or  use  subroutines  to  transfer  data  because 
each  operation  would  be  unique  to  the  others  performed. 

6.1.2  ANALOG 

Internal  to  the  onboard  test  system  all  signals  and  information  are  in 
digital  form.  Therefore,  when  the  DAD  acquires  analogs,  they  are  immediately 
converted  to  digital  form  and  stored  into  memory  to  be  used  for  testing.  When 
the  converted  analog  signals  have  been  stored  in  memory,  additional  processing, 
as  used  for  serial  digital  data,  may  be  necessary  before  utilization  by  the 
test  program.  The  two  methods  which  would  apply  to  analog  data  are  reordering 
and  scaling. 

When  data  is  stored  in  the  memory  of  the  computer  it  is  not  sorted  by 
signal  type,  such  as  analog,  digital,  or  packed  discrete,  but  by  what  system 
they  represent.  This  type  of  segregation  results  in  all  types  of  data  being 
intermixed  in  one  memory  area  of  the  computer.  To  segregate  the  analogs  into 
an  order  which  the  test  program  can  use  the  data  the  signals  must  be  reordered. 
The  reordering  method  is  the  same  as  previously  described  where  the  program 
individually  transfers  each  word  to  a  predetermined  location  in  memory  scratch 
pad.  When  all  data  has  been  transferred  to  their  correct  locations  the  soft¬ 
ware  program  can  continue  and  perform  all  the  required  system  tests. 
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As  in  serial  digital  data,  analogs  may  require  rescaling  before  they  can 
be  used  in  a  mathematical  calculation  or  comparison  test.  The  reasoning  behind 
this  is  that  the  DAD  has  a  certain  A/D  format  for  analog  conversion  whereas  the 
incoming  serial  digital  data,  converted  externally  from  the  test  system,  may 
have  a  different  digital  format.  Rescaling  would  be  required  to  have  common 
format  for  all  the  inputs  for  any  particular  calculation  or  comparison. 

6.1.3  DISCRETE 

When  discrete  signals  are  acquisitioned  by  the  test  system  they  are  con¬ 
verted  from  zero  and  five  volt  readings  to  logic  "0"  and  "1"  bits  in  the  acqui¬ 
sition  unit.  These  logic  "0"  and  "1"  discretes  are  packed  into  16  bit  digital 
words  and  stored  in  memory.  The  packing  order  of  the  discretes  is  dependent 
on  the  wiring  pin  assignments  for  the  DAD.  The  pin  assignments  are  made  using 
the  initial  test  requirements  utilization  of  the  acquisition  discrete  signals 
via  the  DAD.  There  are  four  software  techniques  which  are  available  to  further 
process  and  utilize  this  type  of  data:  1)  Discrete  bit  reordering,  2)  Pattern 
recognition,  3)  Direct  bit  testing,  and  4)  The  data  masking  technique. 

The  technique  of  reordering  and  discretes  within  the  16  bit  word  was  dis¬ 
cussed  before,  but  only  for  packed  discretes  from  other  systems.  In  addition 
to  reordering  within  the  16  bit  word,  new  words  can  be  formed  by  transferring 
bits  from  individual  words  and  repacking  in  memory,  as  shown  in  Figure  6-1. 

As  before,  this  technique  enables  the  software  to  utilize  programing  effi¬ 
ciency  methods  such  as  looping,  or  in  other  words,  reusable  subroutines  stored 
within  the  computer  memory.  The  advantage  of  using  this  technique  would  be  to 
obtain  the  capability  of  reducing  the  memory  size  for  the  onboard  test  system 
software  program.  This  method  was  used  throughout  the  B-l  CITS  software  pro¬ 
gram  and  lead  to  the  generation  of  efficient  software  programming. 

The  pattern  recognition  method  involves  converting  the  zero  and  one  bit 
pattern  for  the  "go"  condition  into  hexadecimal  format.  An  example  of  this 
can  be  illustrated  by  the  following  zero -one  bit  pattern:  "0101001111000101." 
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ETCS  1  Clockwise  Command _ 

ETCS  1  Counterclockwise  Command 

- - - 1 

ETCS  1  Brake  Conmand 

- - — ) 

ETCS  1  Autothrottle  Limit 

- i 

ETCS  1  Motor  Common  Command 


DAU  NO.  3 


FROM  CITS/EMUX  INTERFACE  UNIT  — 

Word  220/011 

Anti-Ice  Valve  Sw.  Pos.,  bit  09 
Word  220/013 

Alternate  Mode  Signal,  bit  11 
Alt.  Mode  Decrease  Command,  bit  13 
Alt.  Mode  Increase  Command,  bit  15 

Word  220/017 

Alt.  Mode  Off  Limit  Switch,  bit  08 
Alt.  Mode  Idle  Limit  Switch,  bit  09 

Word  220/040 

Auto  Throttle  Mode  Signal,  bit  11 
Word  220/050 

Landing  Gear  Limit,  bit  10 

Word  240/111 

Condition  Reset,  bit  09 

Speed  Lockup,  bit  10  _ 


CITS  COMPUTER  SOFTWARE 


PREPROCESSING 
(DATA  REORDERING) 

INTEGRATED 

PROPULSION 

TEST 

MODULE 


SCRATCH  PAD 
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Packed  Discrete  Word 


DAU  NO.  2 


Typical  Reordering  of  Discretes 
for  Engine  No.  1: 

r 

Bit  0  Speed  Lockup 

1  Condition  Reset 

2  Landing  Gear  Limit 

3  Alternate  Mode  Signal 

4  Autothrottle  Mode  Signal 

5  Alt.  Mode  Off  Limit  Switch 

6  Alt.  Mode  Idle  Limit  Switch 

7  Alt.  Mode  Inc.  Command 

8  Alt.  Mode  Dec.  Command 

9  Anti  've  Switch  Position 

10  ETCS  ’■  i  -land 

11  ETCS  1  CCW  v-jmmand 

12  ETCS  1  Brake  Command 

13  ETCS  1  Autothrottle  Limit 

14  ETCS  1  Motor  Com.  Command 


Discrete  Bit  Reordering 
Figure  6-1 
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The  resultant  hexadecimal  number  would  be  "53C5."  The  converted  number  would 
be  stored  in  the  computer  memory  to  be  used  as  a  test  constant  compared  to  the 
incoming  sampled  packed  discrete  word.  To  perform  this  test  using  the  pattern 
recognition  technique  would  involve  acquisitioning  the  packed  discrete  word, 
loading  the  word  into  a  working  register,  loading  another  register  with  the 
stored  "GO"  condition  bit  pattern,  and  comparing  the  two  registers  to  see  if 
they  compare  to  one  another  bit  by  bit.  When  testing  a  system  such  as  the 
B-l  AICS  where  the  majority  of  the  signals  are  serial  digital  discretes,  it 
was  more  efficient  to  use  the  pattern  recognition  method  versus  other  methods 
such  as  direct  bit  testing  and  data  masking.  The  rationale  for  this  choice 
was  made  when  it  was  found  that  after  preprocessing  within  CITS  all  packed 
discrete  configurations  would  be  the  same  for  all  AICS  controllers.  The  com¬ 
monality  of  configuration  for  all  the  packed  discretes  facilitates  the  usage 
of  the  pattern  recognition  test  technique. 

The  advantage  of  direct  bit  testing  enables  the  software  programmer  to 
test  any  one  individual  bit  within  a  packed  discrete  word.  The  advantage  of 
this  method  is  it  requires  very  few  steps  because  it  is  a  direct  usage  of  the 
computer's  capability  to  test  individual  bits.  Also  this  method  has  the  fas¬ 
test  execution  time  of  all  methods  which  makes  it  a  good  candidate  when  time 
and  memory  core  space  are  at  a  minimum. 

The  data  masking  procedure  is  actually  a  form  of  pattern  recognition  where¬ 
by  the  complement  of  the  acceptable  value  of  a  data  word  is  included  in  an  ind- 
vidual  instruction  to  be  compared  to  the  data  word.  Combination  of  the  in¬ 
coming  data  word  with  its  complement  by  means  of  an  "AND"  instruction  should 
give  a  result  of  zero  for  a  "GO"  condition.  This  method  is  used  when  looping 
techniques  are  not  employed  and  has  the  advantages  of  reduced  instructions  and 
ease  of  change,  as  compared  to  normal  pattern  recognition. 

All  of  the  methods  discussed  are  excellent  in  their  application  in  per¬ 
forming  onboard  tests  within  a  computer.  Before  the  test  system  designer  can 
consider  these  techniques  for  his  tests,  he  must  make  sure  that  the  computer 
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used  has  the  needed  capabilities  in  order  that  these  tests  can  be  executed 
properly  and  efficiently. 

6.2  AIRCRAFT  SUBSYSTEM  SICMAL  PROCESSING 

The  processing  of  data  can  either  be  done  in  the  subsystem  under  test  or 
by  the  test  system.  This  section  of  the  design  guide  will  address  processing 
of  signals  within  the  system  under  test.  The  discussion  will  include  signal 
scaling,  signal  conversion,  and  multiplexing  of  data  to  be  transmitted  to  the 
test  system. 

6.2.1  SIGNAL  SCALING 

Most  test  systems  prefer  their  test  signals  to  be  zero  to  five  volts.  The 
reasoning  behind  this  is  to  have  the  capability  to  use  low  power  circuits  in 
the  test  system  and  to  minimize  the  distribution  of  high  power  lines  throughout 
an  aircraft  to  suppress  excess  electrical  noise  from  being  generated.  Test 
signals,  at  their  origin,  can  vary  from  zero  to  twenty-eight  volts,  one  hundred 
volts,  or  four  hundred  volts  depending  on  their  application.  These  are  the 
reasons  for  scaling  all  outputs  to  the  test  system  to  a  zero  to  five  volt  signal. 

The  traditional  scaling  method  used  is  to  utilize  an  operational  amplifier 
circuit  with  resistive  feedback  to  both  scale  down  and  isolate  the  signal  to  the 
test  system.  This  type  of  circuit  will  process  and  scale  the  voltage  ranges 
mentioned  depending  on  the  proper  selection  of  series  and  feedback  resistors. 
When  these  signals  have  been  scaled  by  the  hardware,  it  then  is  possible  to 
further  scale  the  analog  outputs,  internal  to  the  system  under  test,  by  means 
of  converting  to  digital  signals  and  inputting  than  into  a  microprocessor. 
Internal  to  the  microprocessor,  arithmetic  operations  can  be  done  and  the  values 
would  be  scaled  down  further  and  then  converted  back  to  analogs  or  left  as  dig¬ 
ital  words  and  sent  to  the  test  system  for  further  processing. 

The  B-l  aircraft,  for  example,  utilized  the  hardware  scaling  technique 
and  microprocessor  software  method  in  the  Engine  Instruments  Subsystem  (EIS) . 
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The  engine  analog  signals,  with  various  scalings,  were  inputted  into  the 
Signal  Conditioning  and  Distribution  Unit  (SCDIT)  of  the  EIS,  scaled  by  means 
of  resistor-operational  amplifier  and  multiplexed  through  an  A/D  converter  to 
the  microprocessor.  Within  the  SCDU  microprocessor  additional  software  cal¬ 
culations  and  scaling  took  place  being  serially  outputted  to  the  CITS  via  EMLJX. 
These  digital  signals  would  then  be  used  in  the  CITS  engine  test  after  further 
processing  Which  will  be  discussed  in  following  sections. 

6.2.2  SIGNAL  CONVERSION 

There  are  three  types  of  signals,  analog  in  nature,  that  can  be  converted 
into  a  serial  digital  signal  and  transmitted  to  the  onboard  test  system.  The 
three  types  of  signals  are  voltage,  current,  and  frequency. 

Analog  voltages  can  be  directly  converted  to  a  digital  word  via  an  A/D 
converter.  A/D  converters  are  a  plentiful  item  in  the  market  place.  They 
vary  in  bit  length,  speed,  voltage  source  required,  and  cost.  The  various 
techniques  of  conversion  used  by  this  type  of  device  have  been  discussed  in 
detail  in  Section  4.  The  three  basic  techniques  utilized  in  A/D  converters 
are  successive  approximation,  integration,  and  the  counter  method. 

Current  type  signals  are  easily  converted  to  voltage  by  the  use  of  a 
resistor.  When  a  voltage  signal  has  been  produced  the  above  processing  pro¬ 
cedure  would  be  utilized  to  convert  it  to  a  digital  signal. 

Frequency  inputs  are  easily  converted  to  a  voltage  by  the  use  of  a  Vari¬ 
able  Frequency  Oscillator  (VFO)  device.  These  devices  come  in  small  modular 
unit  packages  and  are  controlled  by  DC  voltage.  The  conversion  process  varies 
from  linear  to  nonlinear  relationships  for  input  frequency  versus  output  volt¬ 
age.  When  these  signals  are  converted  to  voltages,  scaling  can  be  done  by 
means  of  operational  amplifiers,  and  digitizing  can  be  accomplished  by  the  A/D 
converters . 
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6.2.3  MULTIPLEXING 

Signal  multiplexing  is  a  method  by  which  many  signals  can  be  transmitted 
on  one  pair  of  wires  versus  one  pair  of  wires  for  each  signal.  This  process 
is  normally  carried  out  by  integrated  circuits  which  are  specifically  designed 
for  this  purpose.  There  are  two  applications  for  this  technique,  serial  dig¬ 
ital,  and  serial  analog  interfaces. 

The  serial  digital  interface  is  usually  a  four  wire  interface,  two  wires 
for  an  address  line  from  the  DAD  to  the  system  under  test  and  two  wires  for  the 
multiplexed  information  to  be  sent  to  the  DAD  from  the  signal  source.  This 
section  focuses  attention  on  those  methods  used  to  process  data  internal  to  the 
system  under  test.  With  this  in  mind,  all  of  the  addressing  and  A/D  conversion 
circuitry  would  be  within  the  system  under  test.  For  signal  multiplexing  to 
take  place,  each  analog  signal  would  have  an  address  or  identifier  number  as¬ 
signed.  The  DAD  would  transmit  a  particular  code  identifying  which  signal  is 
to  be  transmitted.  The  code  would  be  translated  into  a  zero-one  bit  pattern 
and  decoded  in  order  that  the  proper  signal  is  selected  by  the  multiplexer 
circuitry.  Internal  to  the  system  LRU  the  analog  would  be  selected  by  means 
of  a  solid  state  electronic  selector  switch  and  routed  down  a  coirmon  link  to 
the  A/D  converter,  which  is  shared  by  all  signals  being  transmitted  to  the  DAD. 
After  A/D  conversion  is  complete  the  resultant  digital  word  is  clocked  out  of 
its  temporary  storage  register  to  the  DAD  via  the  second  pair  of  wires.  The 
speed  of  this  entire  process  is  in  the  realm  of  microseconds  for  completion. 

It  can  be  seen  that  in  one  second  thousands  of  signals  can  be  acquisitioned 
from  a  system  under  test.  An  example  of  this  method  can  be  seen  in  the  B-l 
engine -mounted  CITS  processor  as  illustrated  in  Figure  6-2.  The  CITS  system 
transmits  an  eight  bit  digital  address  to  the  CITS  processor.  When  the  digital 
word  is  received  it  is  decoded  and  the  proper  analog  signal  is  selected,  A/D 
converter,  and  transmitted  back  to  the  CITS  DAU.  To  send  and  receive  one  simple 
digital  word  takes  approximately  thirty  microseconds.  This  technique  for  proc¬ 
essing  data  has  one  major  advantage  in  that  it  enables  the  elimination  of  a 
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great  many  wires  to  transmit  many  signals  to  the  DAD  for  testing  purposes. 

When  weight  is  a  critical  factor,  this  method  is  a  superior  choice  for  the 
designer  to  make,  when  performing  trade  studies  on  weight,  reliability,  and 
complexity.  When  reducing  weight  using  the  multiplexing  technique,  one  auto¬ 
matically  obtains  higher  reliability  and  reduced  complexity  for  the  system 
under  test.  The  application  of  this  technique  reduces  the  amount  of  elec¬ 
tronic  components  necessary  because  common  usage  by  all  signals  is  obtained. 

The  coimon  usage  parts  would  be  the  A/D  converters,  address  decoder,  elec¬ 
tronic  selector  circuit,  and  the  isolation  amplifiers.  By  reducing  the  circuit 
complexity,  increased  reliability  is  automatically  achieved  because  of  reduced 
cause  of  failure  in  fewer  parts. 

The  second  application  of  the  multiplexing  technique  is  serial  analogs. 

The  circuitry  involved  is  identical  to  the  serial  digital  case  minus  the  A/D 
converter.  The  A/D  conversion  would  be  done  outside  the  LRU's  on  the  system 
under  test.  The  advantages  for  the  serial  analog  are  the  same  as  the  serial 
digital  technique.  An  additional  advantage  is  that  the  complexity  within  the 
LRU  is  decreased  further,  thus  increasing  reliability  and  reducing  weight.  One 
disadvantage  is  that  the  analog  multiplex  signal  is  more  susceptible  to  noise 
than  the  serial  digital  signal,  because  voltage  changes  caused  by  noise  would 
change  the  value  of  the  parameter,  whereas  in  the  digital  signal  the  value 
represented  by  the  zero-one  bit  pattern  is  relatively  fixed  when  sent  from  the 
LRU  to  the  DAD.  The  digital  format  has  minimum  susceptibility  to  noise  because 
the  signal  value  is  determined  by  the  zero -one  bit  pattern  and  not  the  waveform 
magnitude. 

If  the  designer  is  faced  with  interfacing  many  analogs  with  his  test  system 
by  either  of  the  techniques  discussed,  even  with  the  described  disadvantages, 
the  choices  are  better  than  the  added  weight  of  all  of  the  individual  wires  and 
unique  electronics  necessary  for  the  standard  analog  interface. 
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6.3  SUMMARY 

The  three  types  of  signals  normally  encountered  and  accessed  as  test 
parameters  by  a  test  system  are  serial  digital,  analog,  and  discrete.  Each 
type  requires  some  type  of  processing  to  permit  their  use  in  the  test  system. 
The  methods  and  techniques  available  and  recommended  are  dependent  upon  the 
design  requirements  of  the  test  system,  but  generally  evolve  into  the  con¬ 
version  of  analog  and  discrete  signals  into  a  serial  digital  format  which  in 
turn  usually  requires  scaling  and  reordering.  For  large  scale  applications, 
where  numerous  signals  must  be  routed  over  appreciable  distances,  multiplexing 
of  signals  is  recommended  to  save  weight  through  the  reduction  of  wiring. 
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Section  7 


SELF-TEST 


7.0  INTRODUCTION 

An  onboard  test  system  would  normally  consist  of  a  central  computer,  spe¬ 
cial  purpose  computer  or  microprocessor,  subsystem  hardware  interface  units, 
display  device,  and  recording  units.  These  devices  would  exchange  information 
through  standard  interface  circuitry  residing  in  each  unit. 

The  general  purpose  of  the  onboard  test  system  is  to  detect  and  isolate 
failures  of  the  subsystems  being  monitored.  This  function  can  only  be  accom¬ 
plished  if  the  testing  units  are  functioning  properly.  The  function  of  self¬ 
test  is  to  establish  the  health,  on  a  continuous  basis,  of  the  test  system, 
and  to  prevent  results  of  tests  being  conducted  on  other  aircraft  systems  from 
being  outputted  when  test  hardware  failures  occur. 

In  this  section  self-test  techniques  are  discussed  and  lists  of  applicable 
hardware  for  each  type  test  are  presented. 

7.1  INSTRUCTION  COUNTER  TEST 

The  instruction  counter  is  used  by  computer  devices  to  store  the  address 
of  the  instruction  which  is  under  execution  at  any  one  time.  The  character¬ 
istic  of  this  counter  permit  testing  to  only  occur  during  the  initialization 
portion  of  the  computer  program.  The  initialization  portion  of  the  program 
is  executed  by  the  computer  only  when  the  power  is  first  applied  and  before 
normal  program  cycling  is  commenced.  During  the  initialization  tests  the 
hardware  and  instruction  counter  are  tested.  If  the  counter  was  tested  during 
the  normal  cycle,  the  program  would  cease  because  it  would  not  know  where  it 
left  off  on  the  instruction  execution  cycle. 

The  testing  of  the  instruction  counter  involves  loading  the  register  with 
a  value  and  verifying  that  the  computer  circuitry  decrements  that  value  to 
zero  by  observing  a  zero  interrupt.  A  zero  interrupt  will  occur  every  time 
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the  counter  goes  to  zero.  When  zero  interrupts  have  occurred  a  bit  is  set 
by  the  computer  in  a  status  word.  A  computer  interrupt  (whereby  the  com¬ 
puter  ceases  all  instruction  execution)  will  occur  when  inherent  computer 
mechanisms  malfunction,  such  as  when  the  instruction  counter  goes  to  zero. 

The  inherent  function  of  the  counter  demands  that  it  cannot  be  zero,  or  else 
the  computer  ceases  to  function. 

7.1.1  APPLICATIONS 

1.  Computer  Central  Processing  Unit  (CPU). 

2.  Subsystem  Electronic  Controllers  (Digital  Type) 
which  utilize  software  instruct ions. 

7.2  ADDRESSING  AND  DATA  TRANSFER 

The  main  tools  computers  use  to  execute  their  function  are  address  load¬ 
ing  and  data  transferring.  The  technique  used  to  test  these  types  of  func¬ 
tion  is  to  simply  insert  test  cases,  execute  the  function,  and  verify  that 
the  expected  answer  was  present.  To  illustrate  this  the  following  could  be 
used  as  a  model  to  design  tests  for  future  systems.  The  B-l  CITS  CPU  uses 
a  specific  application  of  the  test  technique  described.  The  CPU  self-test 
program  enters  a  predetermined  address  into  an  address  register  and  verifies 
that  it  was  entered  correctly.  If  the  address  loading  test  is  verified  suc¬ 
cessfully,  data  is  loaded  into  a  register,  then  transferred  to  another  reg¬ 
ister,  and  both  registers  are  compared  to  one  another  to  verify  that  they 
have  equivalent  stored  values.  The  following  examples  illustrate  the  indi¬ 
vidual  steps  the  computer  would  take  to  execute  the  two  described  tests. 

Example  7.2 

1.  Address  Loading  Test. 

A.  Define  register  at  address  XXXX. 

B.  Load  address  7ACD  into  address  register  at  location  XXXX. 
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C.  Verify  that  address  7ACD  was  loaded  into  address  register  XXXX 
correctly. 

2.  Data  Transfer  Test. 

A.  Define  data  register  at  address  ZZZZ. 

B.  Load  data  word  8ACD  into  register  at  address  ZZZZ. 

C.  Transfer  data  8ACD  from  register  at  location  ZZZZ  to  register  at 
location  ZZZZ  +  5. 

D.  Verify  that  data  in  location  ZZZZ  is  equivalent  to  data  in  location 
ZZZZ  +  5. 

7.2.1  APPLICATIONS 

1.  Computer  Central  Processing  Units. 

2.  Subsystem  Controllers  (Digital  Type). 

3.  Display  devices  with  digital  interfaces. 

4.  Hardcopy  Printers. 

5.  Digital  Maintenance  Recorder. 

7.3  REGISTER  INDEX  ADDRESSING 

This  type  of  testing  involves  loading  one  register  with  a  fixed  value 
and  another  with  an  index  value.  Index  values  are  values  used  to  increment 
addresses  for  modified  branch  locations  in  a  computer.  When  the  registers 
are  loaded,  the  program  adds  the  index  to  the  register  with  a  fixed  value. 

The  results  are  checked  to  verify  the  function  which  is  vital  to  the  operation 
of  modified  addressing  for  branch  instruction  execution.  This  test  technique 
can  be  illustrated  by  the  following  examples  listing  the  steps  which  the 
computer  would  execute  to  verify  the  Register  Index  Addressing  function . 

Example  7.3 

1.  Define  register  at  address  XXXX  as  register  2. 

2.  Define  register  at  address  XXXX  +  2  as  register  4. 
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3.  Load  index  value  0010  into  register  2. 

4.  Load  address  7ADC  into  register  4. 

5.  Add  register  2  to  register  4  and  store  results  in  register  4. 

6.  Verify  register  to  be  7AEC.  (Note:  7AEC  is  equivalent  to  7ADC 
+  0010  in  hexadecimal  code,) 

7.3.1  APPLICATIONS 

1.  Computer  Central  Processing  Units. 

2.  Microprocessors. 

3.  Subsystem  Digital  Controllers. 

4.  Future  hardware  designs  will  all  incorporate  microprocessors  to 
reduce  cost  and  increase  reliability.  This  change  will  require 
these  hardware  types  to  use  this  self-test  technique: 

A.  Data  Acquisition  Units. 

B.  Hardcopy  Printers. 

C.  Control  and  Display  Units. 

D.  Digital  Maintenance  Recorders. 

7.4  REGISTER-TO-REGISTER  CHECKSUM 

Devices  which  contain  computer  circuitry  have  base  registers  which  are 
used  to  temporarily  store  values  such  as  data,  partial  calculation  results, 
and  program  addresses.  For  this  reason  a  self -test  of  these  functions  is 
very  important.  This  test  involves  loading  all  base  registers  with  fixed 
numbers.  When  this  has  been  accomplished  the  test  program  will  add  and  sub¬ 
tract  the  register  in  different  combinations  and  check  the  results  to  verify 
both  the  register  loading  and  addressing  circuitry.  This  test  technique  is 
widely  used  and  is  identified  as  a  checksum  test.  At  this  point  an  example 
can  be  shown  to  define  the  steps  a  CPU  program  would  execute  to  perform  a 
checksum  test. 
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1.  Define  address  location  XXXX  to  be  register  2. 

2.  Define  address  location  XXXX  +  1  to  be  register  3. 

3.  Define  address  location  XXXX  +  2  to  be  register  4. 

4.  Define  address  location  XXXX  +  3  to  be  register  5. 

5.  Load  register  2  with  hexadecimal  data  of  1111. 

6.  Load  register  3  with  hexadecimal  data  of  1111. 

7.  Load  register  4  with  hexadecimal  data  of  1111. 

8.  Load  register  5  with  hexadecimal  data  of  1111. 

9.  Add  register  2  to  register  3  and  store  results  in  register  3. 

10.  Add  register  3  to  register  4  and  store  results  in  register  4. 

11.  Add  register  4  to  register  5  and  store  results  in  register  5. 

12.  Subtract  register  5  from  register  2  and  store  results  in  register 

2.  Verify  checksum  in  register  2  to  be  -3333  which  has  an  equiv¬ 
alent  hexadecimal  code  of  CCCD. 

7.4.1  APPLICATIONS 

1.  Computer  Central  Processing  Units. 

2 .  Microprocessors . 

3.  Subsystem  Digital  Controllers. 

4.  For  future  hardware  units,  utilizing  microprocessors,  the  following 
would  use  this  technique: 

A.  Data  Acquisition  Units. 

B.  Hardcopy  Printers. 

C.  Control  and  Display  Units. 

D.  Digital  Maintenance  Recorders. 

7.5  BASIC  INSTRUCTION  FORMAT  OPERATIONS 

During  program  execution,  the  main  functions  which  are  used  the  most  are 
branching  and  data  shifting.  Branching  involves  advancing  from  one  portion 


of  the  program  to  another  in  order  that  instruction  execution  sequencing  can 
be  manipulated.  The  shifting  function  is  used  to  scale  or  modify  data  and 
to  address  indexing  information  for  utilization  in  the  computer  program.  The 
test  technique  utilized  involves  storing  and  manipulating  predetermined  val¬ 
ues,  and  verifying  that  the  appropriate  decision  branching  can  be  executed 
properly.  The  shifting  function  is  checked  in  the  same  manner.  Data  is 
loaded  into  registers  and  shifting  is  executed  and  the  results  are  verified 
to  be  correct.  These  types  of  tests  will  verify  that  the  basic  functions 
operate. 

The  following  example  defines  those  steps  that  the  computer  would  exe¬ 
cute  to  perform  the  branching  and  shifting  functional  checkout. 

Example  7.5 

1.  Branching  Test. 

A.  Define  address  location  XXXX  to  be  register  2. 

B.  Define  address  location  XXXX  +  1  to  be  register  3. 

C.  Load  register  2  with  a  hexadecimal  value  of  5CDE. 

D.  Load  register  3  with  a  hexadecimal  value  of  3CCC. 

E.  Compare  register  2  with  register  3.  Verify  that  computer 
branches  when  register  2  is  greater  in  va]ue  than  register  3. 

F.  Compare  register  3  with  register  2.  Verify  that  computer  bran¬ 
ches  when  register  3  is  less  in  value  than  register  2. 

2.  Shifting  Test. 

A.  Define  address  location  XXXX  to  be  register  2. 

B.  Load  register  2  with  a  hexadecimal  value  of  4444. 

C.  Execute  a  right  shift  instruction  for  one  digit  right. 

D.  Verify  register  2  to  be  a  hexadecimal  of  2222. 
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7.5.1  APPLICATIONS 

1.  Computer  Central  Processing  Units . 

2.  Microprocessors. 

3.  Subsystem  Digital  Controllers. 

4.  Digital  SCDU's. 

5.  Those  future  designs  utilizing  microprocessors  are: 

A.  Data  Acquisition  Units. 

B.  Hardcopy  Printers. 

C.  Control  and  Display  Units. 

D.  Digital  Maintenance  Recorders. 

7.6  MEM3RY  STORAGE  CAPABILITY 

The  storage  capability  test  involves  storing  a  test  constant  into  a  mem¬ 
ory  location  and  extracting  it  again  to  see  if  the  value  has  changed.  When 
the  test  value  is  extracted  from  the  memory  core  it  is  temporarily  stored  in 
one  of  the  address  registers  waiting  for  the  comparison  test  to  take  place. 
The  test  is  done  twice,  using  two  different  portions  of  memory.  This  is  done 
to  check  more  than  only  one  portion  of  the  circuitry,  even  though  there  are 
many  common  circuits  involved  in  the  procedure.  Past  experience  on  the  B-l 
CITS  program  has  shown  this  type  of  testing  to  be  very  reliable  in  proving 
the  functional  health  of  the  memory  storage  capability. 

7.6.1  APPLICATIONS 

1.  Computer  Central  Processing  Units. 

2.  Microprocessors. 

3.  Subsystem  Digital  Controllers. 

4.  Digital  SCDU's 

5.  The  following  represent  those  units  which  will  have  microprocessors 
incorporated  in  the  future  designs: 
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A.  Data  Acquisition  Units. 

B.  Hardcopy  Printers. 

C.  Control  and  Display  Units. 

D.  Digital  Maintenance  Recorders 

7.7  MEM3RY  ADDRESS  INTERPRETER 

The  address  interpreter  test  involves  taking  a  fixed  hexadecimal  con¬ 
stant,  converting  it  to  its  complement  (i.e.,  the  negative  of  the  number), 
and  storing  it  in  an  addressable  location  in  memory.  The  test  continues  on 
by  adding  the  original  constant  to  the  complement  and  verifying  that  the  sum 
is  zero.  The  add  instruction  used  utilizes  addresses  of  the  number  involved 
rather  than  the  actual  numbers  themselves.  This  technique  tests  the  cap¬ 
ability  of  the  memory  to  interpret  the  address  of  the  value  desired  from 
core  memory,  transfer  that  value  to  the  arithmetic  section,  and  obtain  the 
correct  answer.  It  has  been  proven  by  B-l  CITS  experience,  and  in  industry, 
that  the  most  efficient  way  to  test  a  computer  function  is  by  exercising  that 
function  with  known  inputs  and  comparing  the  output  with  the  predictable  re¬ 
sults. 

7.7.1  APPLICATIONS 

1.  Computer  Central  Processing  Units . 

2.  Microprocessors. 

3.  Subsystem  Digital  Controllers. 

4.  Digital  SCDU's. 

5.  Those  future  designs  utilizing  microprocessors  such  as: 

A.  Data  Acquisition  Units. 

B.  Hardcopy  Printers. 

C.  Control  and  Display  Units. 

D.  Digital  Maintenance  Recorders. 
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7.8  INITIALIZATION  TESTING 


Initialization  testing  is  done  during  the  test  system  power-up  sequence 
to  establish  a  starting  point  for  the  program  and  to  determine  the  primary 
health  of  the  hardware.  There  are  tests  which  can  only  be  done  during  the 
initialization  period,  because  they  would  disrupt  the  program  cycle  if  they 
were  tested  at  other  times.  An  example  of  this  type  of  situation  is  the 
program  instruction  counters.  The  program  would  cease  to  run  if  during 
operation  the  instruction  counter  was  set  to  zero  for  a  test.  The  initial¬ 
ization  portion  of  the  computer  checkout  included  memory  checksum  tests, 
interrupt  tests,  counter  tests,  discrete  input/output  test,  and  computer 
channel  tests. 


7.8.1  CHECKSUM  TEST 

The  checksum  test  done  during  the  initialization  portion  of  the  self¬ 
test  program  is  the  same  as  described  in  paragraph  7.4.  This  test  is  one 
of  those  that  can  be  done  during  program  operation  as  well  as  at  initial¬ 
ization,  because  the  operations  involved  are  not  part  of  the  basic  cycling 
mechanisms  of  the  hardware  or  software  program.  When  this  test  is  executed 
during  initialization  it  establishes  the  initial  condition,  at  power  up,  of 
the  register  and  arithmetic  portions  of  the  computer  circuitry. 


7.8.1. 1 


1.  Computer  Central  Processing  Units. 

2.  Microprocessors. 

3.  Subsystem  Digital  Controllers. 

4.  Digital  SCDU's. 

5.  Those  future  designs  utilizing  microprocessors  are: 

A.  Data  Acquisition  Units. 

B.  Hardcopy  Printers. 

C.  Control  and  Display  Units. 

D.  Digital  Maintenance  Recorders. 


7.8.2  INTERRUPTS 


The  basic  function  of  interrupts  is  to  transfer  program  control  from  one 
point  in  the  computer  to  another.  The  B-l  CITS  computer  program  has  16  dif¬ 
ferent  types  of  interrupts.  Table  VII-1  gives  a  listing  of  the  interrupt 
types  and  priority  levels.  Some  of  the  interrupts  are  of  a  failure  type  and 
the  remainder  occur  as  an  event  marker.  When  the  computer  is  executing  the 
instructions  of  the  main  program  and  a  non- failure  type  interrupt  occurs,  the 
hardware  stores  the  address  where  the  computer  leaves  off  and  then  executes 
a  special  subroutine  program  that  performs  operations  which  take  care  of  that 
particular  interrupt  occuring  in  the  program.  When  the  subroutine  has  com¬ 
pleted  its  tasks  the  main  program  is  continued  from  where  the  program  trans¬ 
ferred  control. 

In  conjunction  with  the  interrupt  function,  the  CITS  software  program 
utilizes  a  Program  Status  Word  (PSW) .  The  PSW  carries  the  discrete  status 
of  the  information  contained  in  the  previously  described  list  of  interrupt 
level  assignments.  Each  interrupt  level  has  a  unique  main  store  fullword 
location  assigned  to  the  "old  PSW"  and  one  assigned  to  the  "new  PSW."  The 
zone  of  main  store  containing  these  assigned  PSW  locations  is  called  the 
permanent  storage  area.  Upon  taking  an  interrupt  the  computer  automatically 
stores  the  current  PSW  in  the  main  store  location  assigned  to  the  "old  PSW" 
for  the  level  of  the  interrupt  taken  and  loads  the  contents  of  the  "new  PSW" 
location  into  the  current  program  status  registers  in  the  CPU.  The  old  PSW 
holds  all  the  necessary  status  information  on  the  system  existing  at  the  time 
of  the  interruption.  Execution  of  the  interrupt  routine  begins  at  the  instruc¬ 
tion  location  specified  by  bits  0-15  of  the  new  PSW.  At  the  conclusion  of 
the  interrupt  routine  a  LOAD  PROGRAM  STATUS  WORD  instruction,  specifying  the 
address  of  that  interrupt  level's  old  PSW,  returns  the  machine  status  to  that 
contained  prior  to  entering  the  interrupt  routine  and  the  interrupted  routine 
continues. 


A 
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TABLE  VII-1 


Interrupt  and  Interrupt  Level  Assignments 


Level  Number 

Interrupt  Number 

Interrupt  Description 

0 

0 

Parity  error  on  data  received  by  CPU 

0 

1 

Parity  error  or  memory  not  responsive 

0 

2 

Bad  Data  from  a  peripheral 

0 

3 

Multiple  commands  sent  to  input/output 

0 

4 

GO/NO  GO  overflow 

1 

2 

Arithmetic  oveiflow 

2 

6 

Clock  number  1 

3 

7 

Clock  number  2 

4 

8 

External  number  1 

5 

9 

External  number  2 

6 

10 

External  number  3 

7 

11 

External  number  4 

8 

12 

Input/output  channel  number  1 
termination 

8 

13 

Input/output  channel  number  2 
termination. 

8 

14 

Input/output  channel  number  3 
termination 

8 

15 

Input/output  channel  number  4 
termination 
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The  test  technique  used  for  the  interrupt  function  involves  loading  a 
bad  parity  word  in  a  functional  register  and  observing  the  PSW  to  verify  the 
proper  bit  setting. 

The  only  time  which  lends  itself  to  a  self-test  of  the  interrupt  function 
is  during  the  initialization  period.  If  this  test  were  done  during  the  oper¬ 
ational  mode  of  the  program,  the  computer  would  immediately  discontinue  pro¬ 
cessing  data,  transfer  control  to  a  level  zero  (failure  type)  interrupt  test 
routine,  which  stores  the  address  where  the  error  occurred,  and  would  go  into 
a  secure  mode,  requiring  operator  assistance  to  initiate  a  system  reinitia¬ 
lization. 

7.8. 2.1  Applications 

1.  Computer  Central  Processing  Units. 

2.  Microprocessors. 

3.  Subsystem  Digital  Controllers. 

4.  Those  future  designs  utilizing  microprocessors  are: 

A.  Data  Acquisition  Units. 

B.  Hardcopy  Printers. 

C.  Control  and  Display  Units. 

D.  Digital  Maintenance  Recorders. 

7.8.3  COUNTERS 

The  testing  of  the  counters  is  another  test  that  can  only  be  executed 
during  the  initialization  period.  The  B-l  CITS  system  utilizes  three  dif¬ 
ferent  types  of  functional  counters.  The  first  type  is  the  main  instruction 
counter  which  the  computer  loses  to  store  the  address  of  the  instruction  being 
executed.  This  counter  is  never  tested  because  of  its  inherent  function.  If 
this  circuitry  should  fail  the  computer  would  stop  all  instruction  execution, 
therefore  when  a  failure  does  occur  the  computer  will  secure  itself.  The 
second  type  is  a  program  loadable  counter.  This  type  is  a  countdown  counter, 
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16  bits  in  length,  and  is  program  loadable.  The  counter  is  loadable  from  a 
general  register  and  is  decremented  every  100  microseconds,  with  a  maximum 
count  of  6.55  seconds.  When  the  counter  passes  through  zero,  an  interrupt 
is  generated.  The  testing  of  the  counter  involves  loading  a  constant,  per¬ 
mitting  it  to  decrement  to  zero,  and  verifying  that  an  interrupt  occurs. 

The  third  type  of  counter  is  GO/NO-GO.  This  16  bit  counter  is  both  loadable 
and  readable.  The  counter  is  decremented  every  50  microseconds,  with  a  max¬ 
imum  count  of  3.28  seconds.  When  the  counter  passes  through  zero,  an  inter¬ 
rupt  is  generated  and  the  fault  indicator  is  set.  This  counter  is  not  tested 
because  testing  would  result  in  a  system  secure  situation. 


7. 8. 3.1 

Applications 

1. 

Computer  Central  Processing  Units. 

2. 

Microprocessors . 

3. 

Data  Acquisition  Units. 

4. 

Hardcopy  Printers. 

5. 

Control  and  Display  Units. 

6. 

Subsystem  Digital  Controllers. 

7. 

Digital  SCDU's. 

7.8.4  DISCRETE  INPUT/OUTPUT 

The  function  of  the  discrete  input/output  is  to  transport  sets  of  packed 
discretes,  in  one  16  bit  word,  from  the  interface  units  into  a  dedicated  mem¬ 
ory  location  in  the  computer.  To  test  this  function  during  the  initialization 
period,  self-test  enters  a  predeteimined  pattern  of  16  bit  discretes  into  an 
active  data  register.  The  program  then  branches  to  input/output  control  which 
transports  the  packed  discretes  to  its  dedicated  input/output  memory  location 
and  then  back  to  another  active  data  register.  After  this  has  been  accom¬ 
plished,  control  is  branched  back  to  self-test  where  the  original  register 
data  is  compared  with  the  new  register  data.  The  registers  should  be  equal 
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bit  for  bit  to  pass  this  test.  Passing  this  test  establishes  the  capability 
of  the  discrete  input/output  function  to  transfer  packed  discretes  from  one 
memory  location  to  another  without  transforming  or  dropping  any  discretes  in 
route.  The  testing  of  this  function  is  vital  because  the  discrete  data  is 
used  for:  (1)  The  precondition  set  up  for  all  tests  executed  by  the  subsystem 
test  and  (2)  The  transmission  of  data  relating  status  of  vital  equipment  on 
the  systems  under  test. 

This  test  technique  is  utilized  extensively  in  the  B-l  CITS  program, 
where  thousands  of  discretes  per  second  are  arranged,  transported,  and  de¬ 
coded  for  purpose  of  obtaining  split-second  health  status  of  vital  equipment 
on  the  aircraft. 


7. 8. 4.1 

Applications 

1. 

Microprocessors . 

2. 

Data  Acquisition  Units. 

3. 

Control  and  Display  Units. 

4. 

Subsystem  Digital  Controllers. 

5. 

Digital  SCDU's. 

7.8.5  COMPUTER  CHANNELS 

The  B-l  CITS  application  of  an  onboard  test  system  involves  a  centralized 
general  purpose  computer  with  two  input/output  channels  which  can  be  utilized 
to  interface  directly  with  another  computer  system.  The  following  test  tech¬ 
nique  can  be  used  to  verify  proper  operation.  First  the  input/output  channel 
must  be  disabled  to  prevent  actual  outputs  from  occurring  during  the  test. 

The  second  step  is  to  initiate  an  output  of  predetermined  data  on  the  channel, 
and  verify  if  it  was  executed  by  observing  an  input/output  channel  termination 
interrupt.  By  obtaining  an  interrupt,  verification  is  made  that  the  command 
was  successfully  executed.  This  test  can  be  repeated  for  each  channel  which 
would  exist  in  a  particular  design. 
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v». 

This  type  of  testing  can  only  be  done  during  the  initialization  period 
because  normal  inter-device  communication  is  interrupted  during  the  test. 

If  a  disturbance  in  comnunication  occurs,  vital  equiptnent  data  would  be  lost 
and  misinterpretation  of  the  loss  could  result  ip.  false  indications  by  the 
test  system. 

7. 8. 5.1  Applications 

1.  Computer  Central  Processing  Unit. 

2.  Microprocessor.  s. 

7.9  RANDOM  ACCESS  MEM3RY  (RAM)  TESTS 

There  are  three  techniques  for  testing  RAM  devices:  1)  Duplication, 

2)  Parity,  and  3)  Checkerboard.  The  following  is  a  discussion  of  these  three 
test  techniques. 

7. 9. 1  DUPLICATION 

RAM  devices  have  two  inodes  of  operation,  write  and  read.  The  testing  of 
the  RAM  is  done  while  in  the  read  mode.  When  the  data  is  read  out,  one  from 
each  duplicate  RAM,  each  is  compared  to  the  other,  detecting  an  error  if  a 
mismatch  occurs.  This  method  detects  all  memory  faults  including  multiple 
bit  faults  and  addressing  errors  and  with  additional  circuitry  can  incorporate 
error  correction. 

7.9.2  PARITY 

Single  bit  parity  is  the  simplest  and  most  common  technique  used  in  mem¬ 
ory  fault  detection.  The  implementation  of  this  test  technique  involves  adding 
a  single  bit  to  each  data  word  such  that  the  total  number  of  "ones"  in  that 
word  is  odd  for  odd  parity,  or  even  for  even  parity.  The  test  is  done  when 
data  words  are  read  into  or  extracted  from  the  RAM.  To  pass  the  test  they 
must  have  the  same  parity  chosen  for  implementation,  odd  or  even. 
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7.9.3  CHECKERBOARD 

The  checkerboard  test  technique  (sometimes  referred  to  as  pattern  rec¬ 
ognition)  involves  a  pattern  of  alternating  "zeros"  and  "ones"  to  be  loaded 
and  extracted  from  the  RAM.  The  extracted  data  is  then  verified  to  have  the 
correct  pattern.  To  implement  this  test  technique  a  temporary  storage  lo¬ 
cation  must  be  allocated  to  store  programs  when  displaced  from  tested  locations 
in  the  RAM. 

7.9.4  APPLICATIONS 

1.  Microprocessors. 

2.  Hardcopy  Printers. 

3.  Control  and  Display  Panels. 

4.  Digital  Maintenance  Recorder. 

5.  Subsystem  Digital  Controller. 

6.  Digital  SCDU. 

7.10  READ  ONLY  MEMORY  (ROM)  TESTS 

RDM  devices  function  in  the  same  manner  as  RAM's.  In  this  context  the 
duplication  and  parity  test  techniques  can  be  applied  with  some  modifications. 
The  checkerboard  technique  cannot  be  used  because  no  data  can  be  inputted 
into  the  ROW  device.  The  following  represents  the  modifications  needed  to 
execute  the  duplication  arid  parity  tests. 

7.10.1  DUPLICATION 

The  ROM  device  requires  a  driving  circuit  for  decoding  of  addresses. 

To  implement  the  duplication  test  comparison  a  complete  system  in  parallel 
would  be  added  such  that  each  decoder  circuit  would  drive  its  own  ROM  device. 
The  test  would  compare  instructions/data  that  is  incorporated  in  the  ROM 
design. 
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7.10.2  PARITY 

To  Implement  a  parity  test  on  a  ROM  device  causes  a  problem  because  the 
word  size  within  the  ROM  is  fixed  and  enlarging  them  to  add  the  parity  bit 
is  improper.  This  can  be  relieved  by  adding  a  RAM  device  to  store  the  parity 
bits.  The  designer  should  specify  his  addressing  scheme  very  carefully  such 
that  the  parity  bits  stored  in  RAM  will  always  match  the  instruction/data  lo¬ 
cations  in  ROM  for  proper  test  results. 

7.10.3  APPLICATIONS 

1.  Microprocessors. 

2.  Digital  Maintenance  Recorders. 

3.  Subsystem  Digital  Controllers. 

4.  Digital  SCDU's. 

7.11  FIRST-IN-FIRST-OUT  MEMORY  (FIFO) 

The  FIFO  memory  device  is  similar  to  a  RAM  and  all  of  the  test  techniques 
are  the  same.  The  FIFO  is  best  suited  for  parity  checking  because  it  is  made 
up  of  9  bit  words,  thus  the  ninth  bit  would  be  used  for  parity  checking. 

7.12  OVERTEMPERATURE  CHECK 

Power  supplies  have  a  characteristic  which,  if  left  unchecked,  would 
cause  wide-spread  damage  to  surrounding  electronics  circuits.  The  one  char¬ 
acteristic  that  could  cause  this  fault  is  overtemperature.  When  the  loading 
on  the  power  supply  increases,  the  current  demand  increases,  which  in  tum 
increases  the  temperature  of  the  power  supply  transformer.  As  the  transformer 
increases  in  temperature  the  internal  resistance  increases.  Due  to  the  in¬ 
creased  current  demands  and  increased  resistance  of  the  transformer  windings 
due  to  heat,  the  temperature  has  a  tendency  to  rapidly  increase  and  begin 
to  damage  the  transformer  and  microcircuitry.  To  curtail  possible  damage 
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it  is  recommended  that  the  temperature  at  the  power  transformer  heat  sink  be 
monitored.  If  the  monitoring  of  the  temperature  should  detect  a  high  value 
condition,  warning  can  be  given  to  the  operator  so  that  manual  action  can 
terminate  operation  of  the  overheated  equipment. 

7.12.1  APPLICATIONS 

1.  Computer  Central  Processing  Unit. 

2.  Microprocessor. 

3.  Data  Acquisition  Unit. 

4.  Hardcopy  Printer. 

5.  Control  and  Display. 

6.  Digital  Maintenance  Recorders. 

7.  Subsystem  Digital  Controllers. 

8.  Digital  SCDU's. 

7.13  ANALOG  CHANNEL  TEST 

Normally  there  are  many  analog  signals  coming  from  the  system  under  test 
to  the  onboard  test  system.  A  typical  configuration  would  consist  of  many 
analog  signals  coming  into  dedicated  operational  amplifier  circuits  for  iso¬ 
lation  purposes,  then  to  an  analog  multiplex  from  where  the  signals  are  fed 
to  an  analog  to  digital  (A/D)  converter,  and  finally  to  storage  in  address¬ 
able  data  registers  for  future  use.  This  type  of  configuration  can  expe¬ 
rience  several  kinds  of  failures.  Typical  failures  include:  (1)  Shorted 
operational  amplifier,  (2)  Non-linear  amplifier,  (3)  Zero  offset,  (4)  A/D 
converter  problem  in  either  the  most  significant  bits  (MSB)  or  the  least 
significant  bits  (LSB)  of  the  resultant  digital  word.  These  failures  can 
be  detected  by  a  test  which  utilizes  the  same  technique  three  times,  but 
uses  three  different  fixed  inputs.  First,  a  ground  test  is  done  by  grounding 
all  analog  inputs  and  observing  the  resultant  A/D  outputs.  If  a  channel 
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exceeds  zero  plus  or  minus  a  fixed  constant,  it  is  considered  as  failed. 
Secondly  the  test  designer  would  have  to  pick  two  other  values  to  insert 
for  A/D  conversion  to  verify  linearity  of  the  circuits.  This  type  of  test 
technique  will  also  detect  shorted  isolation/scaling  amplifiers  and  erroneous 
A/D  converters.  The  interface  unit  used  on  the  B-l  aircraft  CITS  is  called 
the  DAU  and  utilizes  a  number  of  analog  channels.  The  CITS  application  used 
-4.85V,  OV,  and  +4. 05V  as  the  three  input  constants  for  linearity  testing 
because  the  analog  range  was  -5V  to  +5V.  Other  aircraft  applications  could 
have  different  analog  ranges,  such  that  different  input  constants  would  be 
selected. 

7.13.1  APPLICATIONS 

1.  Data  Acquisition  Devices. 

2.  Subsystem  Digital  Controllers. 

7.14  DISCRETE  CHANNEL  TEST 

The  discrete  input  channel  can  be  tested  by  applying  a  logic  "1"  and  a 
logic  "0"  alternately  to  the  input  of  each  discrete  channel  being  tested. 

This  test  technique  is  utilized  on  the  B-l  CITS.  Each  channel  is  tested  in 
the  manner  described  and  status  bits  are  set,  communicating  channel  health 
to  the  computer  for  information  display  and  recording. 

This  test  technique  is  applicable  to  other  systems  where  discrete  input 
channels  exist,  but  timing  of  the  test  is  crucial.  The  B-l  CITS  DAU  executes 
this  test  only  when  no  sampling  of  those  channels  involved  is  taking  place. 

If  sampling  and  testing  were  confused  or  overlayed,  erroneous  information 
would  be  inputted  to  the  system  and  many  false  indications  would  arise. 

7.14.1  APPLICATIONS 

1 .  Microproce  s  sor s . 

2.  Data  Acquisition  Units. 

3.  Control  and  Display  Devices. 
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7.15  SERIAL  DIGITAL  CHANNEL  TEST 


Serial  digital  input  channels  can  be  tested  by  applying  two  different 
17  bit  patterns  to  each  of  the  input  channels.  The  bit  patterns  are  selected 
to  test  each  bit  in  both  logic  level  states.  There  are  two  areas  of  appli¬ 
cation  of  this  test  technique:  (1)  Serial  digital  channel  test  used  in  the 
B-l  CITS  and  (2)  B-l  engine  mounted  CITS  processor  serial  digital  interface 
circuitry.  The  B-l  CITS  DAU  has  several  serial  digital  input  channels  that 
are  tested  in  the  manner  described.  The  results  of  these  tests  are  stored 
in  status  registers,  available  for  computer  scanning,  information  display, 
and  recording.  The  engine  mounted  CITS  processor  utilizes  this  test  technique 
and  sends  two  serial  digital  words  to  CITS  via  an  interface  to  the  DAU.  These 
check  words  are  compared  to  fixed  constants,  with  tolerances  applied,  and  are 
either  determined  to  pass  or  fail.  This  type  of  test  is  excellent  because 
it  tests  the  entire  serial  digital  channel  and  enables  one  to  execute  an  end- 
to-end  test  of  the  involved  circuitry. 

7.15.1  APPLICATIONS 

1.  Microprocessors. 

2.  Data  Acquisition  Units. 

3.  Hardcopy  Printers. 

4.  Control  and  Display. 

5.  Digital  Maintenance  Recorders. 

6.  Subsystem  Digital  Recorders. 

7.  Digital  SCDU's. 

7.16  INPUT/OUTPUr  BUFFER  SELF-TEST 

The  interface  device,  if  separate  from  the  computer  unit,  must  have 
interface  circuitry  installed  in  order  that  two-way  comnunications  between 
the  interface  device  and  computer  can  take  place.  The  interface  circuitry 
would  include,  as  a  major  element,  an  input/output  buffer.  To  test  this 
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portion  of  the  circuitry,  the  computer  would  issue  a  code  to  prepare  the 
interface  device  to  receive  a  string  of  data  words.  The  data  words  received 
are  stored  in  the  input  buffer,  but  are  not  processed  as  normal  data.  When 
the  transmission  is  complete,  the  contents  of  the  input  buffer  are  stored  in 
the  output  buffer  until  a  transmit  data  command  from  the  computer  is  received. 
The  computer  transmits  a  command  to  the  interface  device  to  send  the  contents 
of  the  output  buffer.  When  the  computer  receives  the  data,  it  is  compared  to 
the  original  data  words  it  sends,  and  if  they  match,  the  test  has  passed.  In 
other  words,  the  transmitted  data  and  the  received  data  must  be  the  same  for 
all  the  interface  circuitry  to  be  functioning  properly. 

7.16.1  APPLICATIONS 

1.  Computer  Central  Processing  Unit. 

2 .  Microprocessor . 

3.  Data  Acquisiton  Units. 

4.  Hardcopy  Printers. 

5.  Control  and  Display  Devices. 

6.  Digital  Maintenance  Recorders. 

7.  Subsystem  Digital  Controllers. 

8.  Digital  SCDU’s. 

7.17  OUTPUT  LOGIC  SELF -TEST 

The  output  logic  self- test  should  be  conducted  automatically  in  a  con¬ 
tinuous  mode.  After  completion  of  an  output  data  message  transmission  from 
a  control  and  display  device,  the  output  data  memory  should  be  sent  to  the 
logic  zero  state.  Each  memory  element  would  then  be  individually  set  to  a 
logic  one  state  and  the  memory  element  outputs  monitored  for  a  logic  one  con¬ 
dition.  A  logic  zero  condition  in  the  memory  elements  during  the  monitoring 
then  would  be  designated  as  a  failure  of  the  control  and  display  device. 

This  type  of  test  should  be  inhibited  when  the  keyboard,  if  any,  is  being 
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used  because  operation  would  differ  in  the  manual  mode  from  that  in  the  auto¬ 
matic  display  mode. 

7.17.1  APPLICATIONS 

1.  Hardcopy  Printers. 

2.  Control  and  Display  Devices. 

7.18  DISPLAY  LOGIC  SELF-TEST 

The  display  logic  self-test  would  be  enabled  and  disabled  by  the  computer. 
The  enable  and  disable  commands  should  have  transmission  codes  in  the  computer 
such  that  confusion  between  the  two  is  eliminated.  The  control  and  display 
device  logic  circuitry  would  retain  the  display  logic  self-test  "enabled"  or 
"disabled"  state  until  a  new  command  from  the  central  computer  was  received. 
During  power  initialization  testing  or  computer  reset,  the  display  logic  self¬ 
test  would  assume  the  "enabled"  state.  When  enabled  the  display  logic  self¬ 
test  would  occur  once  each  time  the  control  and  display  device  is  communicated 
with  and  also  in  conjunction  with  the  display  logic.  After  completion  of  all 
input  data  validation  tests,  all  input  data  would  be  stored  in  a  buffer  memory. 
Each  discrete  of  the  data  words  represents  the  test  results  in  two  lights  in 
the  display  device.  The  test  approach  used  on  the  indicator  lights  involves 
the  hardware  injecting  a  very  short  voltage  pulse  and  observing  the  resultant 
current  developed,  and  coirparing  it  to  a  fixed  constant  plus  or  minus  a  tol¬ 
erance.  This  test  technique  has  demonstrated  valid  results  on  checking  light 
bulbs  in  the  B-l  CITS  control  and  display  panel,  therefore  it  should  give 
equal  success  in  future  design  projects. 

7.18.1  APPLICATIONS 

1.  Control  and  Display  Devices. 
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7.19  INTERFACE  ECHO  TEST 


The  interface  echo  test  is  computer  controlled  and  involves  inter-com¬ 
munication  between  the  computer  and  the  peripheral  devices.  The  computer 
would  send  a  data  word  storage  address,  a  data  word,  and  information  telling 
the  interface  device  that  a  test  was  in  progress.  Upon  completion  of  the 
transmittal  of  the  data,  the  computer  would  transmit  information  to  obtain 
the  data  word  back  from  the  interface  device.  Once  the  computer  receives 
the  data  word,  a  comparison  is  made  with  the  original  data  word.  For  the 
test  to  pass,  both  data  words  must  be  the  same  value.  This  test  technique 
is  valid  for  all  devices  which  have  a  two-way  interface  with  a  computer.  It 
has  been  successfully  used  on  the  B-l  CITS  system  inter-hardware  interfaces. 

7.19.1  APPLICATIONS 

1.  Computer  Central  Processing  Unit. 

2.  Microprocessors. 

7.20  PARITY  ERRORS 

Onboard  test  peripherals  require  two-way  communication  with  the  central 
computer  such  that  when  data  are  sent  to  them,  a  response  of  receipt  can  be 
returned.  The  data  which  are  sent  for  output  are  in  the  form  of  sixteen  bits 
plus  one  bit  for  odd  or  even  parity,  thus  resulting  in  seventeen  bits  trans¬ 
mitted.  When  the  word  is  sent  to  the  peripheral  device,  it  is  checked  for 
odd  or  even  parity  by  the  self-test  circuitry.  Upon  determining  the  validity 
of  the  word,  pertinent  information  on  the  status  is  transmitted  to  the  com¬ 
puter  for  processing.  Odd  parity  is  tested  by  verifying  that  there  is  an  odd 
number  of  logic  ones  (for  even  parity  an  even  number  of  logic  ones)  in  the 
seventeen  bit  word.  For  example,  if  the  computer  were  to  send  a  word  of  all 
logic  "ones",  it  would  have  to  add  the  seventeenth  bit  of  logic  "one"  to  re¬ 
sult  in  a  valid  odd  parity  word. 
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This  test  technique  is  a  standard  method  of  checking  data  words  being 
transmitted  or  received  on  a  serial  digital  transmission  line. 

7.20.1  APPLICATIONS 

1.  Computer  Central  Processing  Unit. 

2 .  Microproce  s  sor . 

3.  Data  Acquisition  Units. 

4.  Hardcopy  Printers. 

5.  Control  and  Display  Devices. 

6.  Digital  Maintenance  Recorders. 

7.  Subsystem  Digital  Controllers. 

8.  Digital  SCDU's. 

7.21  1555  DATA  BUS  PROTOCOL  TESTS 

The  input/output  bus  protocol  as  defined  in  MIL-STD-1S53B  requires  the 
peripheral  hardware  to  recognize  certain  transmission  errors.  As  an  example, 
the  CITS  hardcopy  printer  must  respond  to  these  types  of  errors  in  a  fixed 
format  on  the  printer  message  output.  The  following  represents  two  tests 
that  can  be  used  to  verify  proper  protocol  on  the  data  bus. 

7.21.1  NON -VALID  DATA  WORD 

A  non- valid  data  word  can  be  caused  by  such  errors  as: 

1.  Bad  word  parity. 

2.  Non -Manchester  codes. 

3.  Short  word,  i.e.,  missing  bits. 

The  printer,  in  recognition  of  this  error,  would  replace  the  incoming 
data  word  with  a  fixed  pattern  that  replaces  the  printed  characters  with  a 
known  character  such  as  question  marks.  The  printer,  to  detect  such  an  error 
would  compare  the  data  word  format  to  all  legal  formats  and  codes  stored  with 
in  its  memory  and  if  a  match  does  not  occur  with  one  of  the  proper  codes  an 
error  has  been  detected. 
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7.21.2  NON-VALID  MESSAGE 

When  the  computer  is  transmitting  data  to  the  printer  for  printing,  it 
must  communicate  to  the  printer  the  exact  number  of  data  words  it  is  sending 
in  one  string.  The  printer  receives  the  control  message  with  the  data  word 
string  count,  waits  for  the  entire  data  string  to  be  transmitted,  and  then 
the  self-test  circuitry  verifies  that  the  sent  number  of  data  words  agrees 
with  the  intended  number.  If  there  is  a  disagreement,  the  printer  self-test 
will  declare  the  message  sent  to  be  non-valid  and  print  a  known  pattern  at 
the  end  of  the  message  printed,  such  as  underline  characters,  to  notify  the 
reader  that  the  message  is  in  error. 

7.21.3  APPLICATIONS 

1.  Computer  Central  Processing  Unit. 

2.  Microprocessor. 

3.  Data  Acquisition  Units. 

4.  Hardcopy  Printers. 

5.  Control  and  Display  Devices. 

6.  Digital  Maintenance  Recorders. 

7.22  POWER  SUPPLY  VOLTAGE  REGULATION 

The  power  supplies  for  the  onboard  test  system  hardware  units  are  voltage 
regulated  and  designed  such  that  maximum  protection  is  provided  for  the  circuit 
components .  Protective  measures  include  prevention  of  equipment  damage  caused 
by  overvoltage,  undervoltage,  or  transient  conditions  of  the  supply  AC  voltage. 
Overvoltage  and  undervoltage  protection  are  important  because  overvoltage  on 
the  input  power  tends  to  cause  the  power  supply  to  operate  at  a  higher  than 
normal  temperature,  whereas  the  undervoltage  condition  causes  the  user  devices 
to  become  unstable  and  make  random  logic  errors. 

As  in  the  input  power  undervoltage  case,  deregulation  of  output  would 
also  cause  instability  of  the  unit  circuitry.  Regulation  should  be  within 
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plus  or  minus  five  percent  of  the  normal  DC  voltage  required  for  operation. 

The  output  voltage  of  the  power  supply  should  be  monitored  by  the  test  system 
and  declared  failed  if  the  readings  exceed  plus  or  minus  five  percent.  If 
the  voltage  were  allowed  to  exceed  the  test  limits,  possible  damage  would  be 
evidenced  in  the  unit  electronic  components  of  the  test  system. 

7.22.1  APPLICATIONS 

1.  Computer  Central  Processing  Unit. 

2 .  Microp  roce  s  sor  s . 

3.  Data  Acquisition  Units. 

4.  Hardcopy  Printers. 

5.  Control  and  Display  Devices. 

6.  Digital  Maintenance  Recorders. 

7.  System  Digital  Controllers. 

8.  Digital  SCDU's. 

7.23  READ-AFTER-WRITE  TEST 

The  read-after-write  self -test  applies  to  digital  maintenance  recorders. 
The  test  involves  the  following  procedure: 

When  the  recorder  is  in  the  write  mode,  and  in  the  process  of  recording 
on  magnetic  tape,  the  recorder  would  compare  each  bit  of  the  data  read  from 
the  tape  with  each  bit  of  the  data  stored  in  the  registers  for  recording. 

If  a  mismatch  is  found  the  self -test  circuitry  should  do  two  tasks: 

1.  Communicate  that  an  error  was  found  to  the  central  processing  unit. 

2.  Set  a  non -valid  bit  in  the  recorded  data  word  to  communicate  the 
problem  to  the  data  user. 

This  type  of  test  would  not  require  computer  initiation  but  would  be  done 
on  a  continuous  basis  when  the  recorder  is  performing  its  recording  function. 
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7.24  SUNMARY 

This  section  describes  twenty-seven  different  types  of  self-tests  and 
their  hardware  application  that  a  designer  could  choose  from  for  an  onboard 
test  system  design.  Table  VII -2  is  presented  to  summarize  the  tests  and 
their  applications  to  different  hardware  units.  Table  VII-3  is  included  to 
illustrate  those  tests  and  what  hardware  units  they  were  applied  to  for  the 
B-l  aircraft. 
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Self-Test  Applications 
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Future  hardware  will  incorporate  microprocessors  to  reduce  cost  and  increase  reliability. 


B-l  CITS  Self-Test  Experience 
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Performed  by  computer  software  with  variable  patterns. 
Checkerboard  technique. 
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MIL-HDBK-472 

MIL-STD-415 

MIL-STD-454 

MIL-STD-490 

MIL-STD-704 

MIL-STD-721 

i 

MIL-STD-882 

MIL -STD- 1309 

MIL-STD-1345 

MIL-STD-1553 
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REFERENCES 

Maintainability  Prediction 

Test  Provisions  for  Electronic  Systems  and  Associated 
Equipment,  Design  Criteria  For 

Standard  General  Requirements  for  Electronic  Equipment 
Specification  Practices 

Electric  Power,  Aircraft,  Characteristics,  and  Utili¬ 
zation  Of 

Definitions  of  Effectiveness  Terms  for  Reliability, 
Maintainability,  Human  Factors,  and  Safety 

System  Safety  Program  for  Systems  and  Associated  Sub¬ 
systems  and  Equipment,  Requirements  For 

Definition  of  Terms  for  Test,  Measurement,  and  Diag¬ 
nostic  Equipment 

Data,  Measurement,  In  Support  of  Maintenance,  Cali¬ 
bration,  and  Repair  of  Electronic  Equipment 

Aircraft  Internal  Time  Division  Command/Response 
Multiplex  Data  Bus 
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MIL-STD-1591 


On-Aircraft,  Fault  Diagnosis,  Subsystems,  Analysis/ 
Synthesis  Of 


MIL-STD-1629 


Procedures  for  Performing  A  Failure  Mode  and  Effects 
Analysis  for  Shipboard  Equipment 


MIL-STD-2076 


Unit  Under  Test  Compatibility  With  Automatic  Test 
Equipment,  General  Requirements  For 


MIL-F-9490  Flight  Control  Systems  -  Design,  Installation,  and 

Test  Of,  Piloted  Aircraft,  General  Specification  For 

S. 


MIL-H- 8991 


» 
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Rockwell  Missile  Systems  Design,  AH-64  Hellfire  Missile  Equipment  -  Fault 
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ACRONYMS  AND  ABBREVIATIONS 


A 

Availability 

A/C 

Aircraft 

A/P 

Airborne  Printer 

ACUC 

Avionics  Control  Unit  Complex 

ADC 

Analog  to  Digital  Converter 

AFR 

Air  Force  Regulation 

AGE 

Aerospace  Ground  Equipment 

AICS 

Air  Induction  Control  System 

AMUX 

Avionics  Multiplex 

APU 

Auxiliary  Power  Unit 

ASCII 

American  Standard  Code  for  Information  Interchange 

ATE 

Automatic  Test  Equipment 

BIT 

Built-In-Test 

BITE 

Built -In-Test  Equipment 

CCD 

CITS  Control  and  Display 

CCSE 

Common  Computer  Support  Equipment 

CCW 

Channel  Control  Word 

CDC 

CITS  Dedicated  Computer 

CDR 

Critical  Design  Review 

CDR 

Crash  Data  Recorder 

CITS 

Central  Integrated  Test  System 

CMR 

CITS  Maintenance  Recorder 

CPDP 

Computer  Program  Development  Program 

CPU 

Central  Processing  Unit 

CRT 

Cathode  Ray  Tube 
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D 

DAD 

DAC 

DACU 

DAD 

DOD 

DSB 

DSP 

ECS 

EMP 

EMUX 

FD/FI 

FMEA 

QIACU 

GRT 

GTS 

HOL 

HW 

I 

ICD 

ILSW 

I/O 

IOC 

IOU 

KYBD 


Detection  Assurance 
Data  Acquisition  Device 
Digital  to  Analog  Converter 
Defensive  Avionics  Control  Unit 
Data  Aquisition  Unit 
Department  of  Defense 
Data  Storage  Buffer 
Debug  Simulation  Program 

Environmental  Control  System 
Electromagnetic  Pulse 
Electrical  Multiplex 

Failure  Detection/Fault  Isolation 
Failure  Modes  and  Effects  Analysis 
Guidance  and  Navigation  Avionics  Control  Unit 
Ground  Readiness  Test 
Ground  Test  System 

High  Order  Language 
Half  Word 

Isolation  Certainty 
Interface  Control  Document 
Interrupt  Level  Status  Word 
Input/Output 
Input/Output  Control 
Input/Output  Unit 

Keyboard 
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SCDU 

S/M 

SRIJ 

STE 

SUT 

TAG 

TBD 

TIC 

“IMDE 

T/R 

T/S 

UUT 

VFO 

WDACU 

X 


Signal  Conditioning  and  Distribution  Unit 

Sample/Hold 

Shop  Replaceable  Unit 

Special  Test  Equipment 

System  Under  Test 

Test  Adapter  Controller 

To  be  Determined 

Transfer  Initiate  Command 

Test,  Measurement,  and  Diagnostic  Equipment 

Transfer/'  Rece  ive 

Time  Slot 

Unit  Ihder  Test 

Variable  Frequency  Oscillator 
Weapon  Delivery  Avionics  Control  Unit 

Failure  Rate 
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Appendix  A 

ONBOARD  TEST  SYSTEM  SPECIFICATION 


This  section  contains  a  suggested  format  and  content  as  a  guideline  for 
the  preparation  of  a  specification  which  encompasses  the  overall  requirements 
for  a  typical  onboard  test  system.  Specific  details  and  wording  are  not  nec¬ 
essarily  included  because  of  the  possible  variations  arising  from  different 
applications.  Those  requirements  which  are  felt  to  be  mandatory,  as  a  minimum, 
are  included  without  regard  to  weapon  system  variances. 

1.  SCOPE 

1.1  Scope.  This  specification  established  the  performance,  design,  develop¬ 
ment,  and  test  requirements  for  an  onboard  test  system. 

1.2  Applicability.  The  requirements  contained  in  this  basic  specification 
shall  apply  to 

2.  APPLICABLE  DOCUMENTS 

2.1  Applicability.  The  following  documents  of  the  exact  issue  shown  form  a 
part  of  this  specification  to  the  extent  specified  herein.  Unless  otherwise 
specified,  in  the  event  of  conflict  between  the  documents  listed  below  and 
the  contents  of  this  specification,  the  contents  of  this  specification  shall 
be  considered  a  superseding  requirement. 

2.2  Government  Documents 
Standards 
Specifications 
Other  Publications 
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3.  REQUIREMENTS 


3.1  Item  Definition.  The  onboard  test  system  is  a  weapon  system  subsystem 

which  continually  tests  the  operability  of  all  weapon  system  systems,  sub¬ 
systems,  and  equipment.  The  onboard  test  system  displays  malfunction  data 
to  the  aircrew  for  evaluation  of  mission  capability  and  records  and  displays 
data  for  maintenance  crews  to  facilitate  weapon  system  repair.  The  onboard 
test  system  is  comprised  of _ _ . 

3.2  Interface 

3.2.1  Definition.  The  onboard  test  system  interface  diagram  shown  in  Figure 
illustrates  the  major  components  of  the  test  system  with  their  interface 

relationship  to  other  weapon  system  systems,  subsystems,  and  equipment. 

3.2.2  Identification 

3.2.2. 1  Support  Subsystems  Interface.  The  onboard  test  system  shall  interface 
with  the  following  support  subsystems: 

A.  Electrical  power  generation  and  distribution  (power  power  via  hard 
line) . 

B.  Environmental  control  (for  cooling  via  ducting). 

3. 2. 2. 2  Weapon  System  Subsystems  Interface.  The  onboard  test  system  shall 

interface  with  equipment  of  the  following  subsystems  as  shown  in  Figure  _ . 


3.2.3  Signals 


3. 2. 3.1  Input  Data  Signals.  The  onboard  test  system  shall  be  capable  of 
receiving  from  the  interfacing  systems,  subsystems,  and  equipment  the  fol¬ 
lowing  types  of  input  signals  for  processing: 

A.  DC  Analogs  0.0  to  plus  or  minus  5.0  volts 

dc  plus  or  minus  1  percent  of 
full  scale. 

B.  Discretes  0.0  to  plus  or  minus  2.0  volts 

dc  (logic  "0") . 

Plus  2.5  to  plus  6.0  volts  dc 
(logic  "1"). 

C.  Serial  Digital  Each  word  _  bits  plus  parity 

bit,  _ mhz. 

3. 2. 3. 2  Output  Signals.  The  onboard  test  system  shall  be  capable  of  sending 
to  the  interfacing  systems,  subsystems,  and  equipment  the  following  types  of 
output  signals  for  testing: 

A.  Discrete  0.0  to  plus  or  minus  1.0  volts  dc 

(logic  "0"). 

Plus  5.0  plus  or  minus  1.0  volts 
dc  (logic  "1") . 

B.  Serial  Digital  Each  word _ bits  plus  parity 

bit,  __  mhz. 

3.2.4  Aerospace  Ground  Equipment  (AGE) .  The  components  of  the  onboard  test 
system  shall  interface  with  the  applicable  AGE.  The  test  system  interfaces 
required  for  onboard  servicing,  handling,  and  testing  shall  be  so  located  as 
to  permit  interconnection  of  the  AGE  with  the  onboard  test  system  installed 
in  its  normal  operating  position  in  the  weapon  system. 

3. 3  Characteristics 

A- 3 


3.3.1  Functional.  The  onboard  test  system  shall  provide  for  the  onboard  test 
of  the  systems,  subsystem,  and  equipment  specified  in  3. 2. 2. 2. 

3. 3. 1.1  Detection  Assurance.  The  onboard  test  system  shall  provide  an  assur¬ 
ance  of  at  least _ percent  that  system  performance  is  operationally  acceptable 

or  that  an  indicated  failure  is  valid  during  in-flight  or  ground  operation. 

3. 3. 1.2  Isolation  Certainty.  The  onboard  test  system  shall  provide  isolation 

of  a  detected  failure  to  an  LRU  with  a  certainty  of  at  least  _  percent. 

3. 3. 1.3  Availability.  The  onboard  test  system  shall  incorporate  those  design 

characteristics  essential  to  the  achievement  of  an  operational  weapon  system 
availability  of  not  less  than  _  percent. 

3. 3. 1.4  Reliability.  The  onboard  test  system  shall  incorporate  those  design 
characteristics  essential  to  the  achievement  of  a  mean-time-between-failure 
(MTBF]  greater  than  _  hours. 

3. 3. 1.5  Maintainability  (Quantitative) .  The  onboard  test  system  shall  incorp¬ 

orate  those  design  characteristics  essential  to  the  achievement  of  a  maintain¬ 
ability  requirement  of  no  less  than  _  percent  for  organizational  level  main¬ 

tenance  . 


3. 3.1.6  False  Indication  Rate  -  The  occurrence  of  a  false  indication  of  a  system, 

subsystem,  or  equipment  status  shall  not  exceed  _  percent. 

3.3.1. 7  Automaticity.  The  test  function  shall  be  essentially  automatic. 

The  manual  or  semiautomatic  approach  shall  be  held  to  an  absolute  minimum 
and  shall  be  utilized  only  when  operational  requirements  preclude  the  use 

of  automaticity  or  no  other  technique  will  satisfy  the  automatic  test  require¬ 
ment. 
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3. 3. 1.8  Radiation  Silence.  The  onboard  test  system  shall  be  capable  of 
evaluating  and  testing  system,  subsystem,  or  equipment  performance  when 
radiating  systems  are  either  radiating  or  observing  radiation  silence. 

3. 3. 1.9  Self-Test.  The  onboard  test  system  shall  be  capable  of  automatically 
performing  a  self-test  of  all  internal  test  operations  either  on  a  continuous 
or  periodic  basis,  or  a  combination  of  both. 

3.3.1.10  Fail  Safe.  The  onboard  test  system  shall  not  cause  failure  or 
degradation  of  the  operational  performance  of  the  weapon  system  in  the 
event  of  a  malfunction  of  the  onboard  test  system. 

3.3.1.11  Display.  The  status  display  for  the  onboard  test  system  shall 
clearly  indicate  the  status  of  the  systems,  subsystems,  or  equipments  while 
operating  in  flight  or  on  the  ground.  No  special  catalogs  or  handbooks  shall 
be  required,  and  no  understanding  of  special,  complex  coded  language  shall  be 
required  of  the  flight  crew  to  determine  total  weapon  system  status  and 
performance  while  in  flight. 

3.3.1.12  Test  Techniques.  The  onboard  test  system  shall  perform  an  integrated 
test  of  weapon  system  systems,  subsystems,  and  equipment,  utilizing  combined 
end-to-end  dynamic  testing  to  the  maximum  extent  possible.  The  integrated 
test  approach  shall  be  applied  to  system  functions  which  use  groups  of  sub¬ 
systems  to  derive  a  mission  required  parameter.  During  the  in-flight  con¬ 
dition,  maximum  use  shall  be  made  of  dynamic  parameters  within  the  subsystem 
resulting  from  the  operational  environment  of  the  subsystem  or  weapon  system 

as  test  stimuli.  When  actual  operational  parameters  are  not  available  or 
usable  for  test  purposes,  the  test  technique  shall  dynamically  exercise  the 
subsystem  in  a  manner  which  accurately  simulates  the  actual  operational  environ¬ 
ment  of  the  subsystem.  The  test  technique  shall  utilize  carefully  selected  test 
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points  which  will  be  capable  of  providing  multiple  parameter  data  rather  than 
a  single  usable  parameter  for  each  test  point.  The  test  technique  shall  min¬ 
imize  reliance  on  the  analysis  of  series  point -by-point  test  results. 

3.3.2  Physical. 

3. 3. 2.1  Weight.  The  target  weight  for  the  onboard  test  system  including 

installation  provisions  is  included  in  the  empty  weight  of  the  weapon  system 
as  specified  in _ . 

3. 3. 2. 2  Volume.  The  volume  of  those  portions  of  the  onboard  test  system  not 

contained  within  LRU's  of  other  systems,  subsystems,  or  equipment  shall  not 
exceed  a  total  of _ cubic  feet. 

3.3. 2.3  Power.  The  onboard  test  system  shall  perform  within  the  requirements 

specified  herein  while  operating  from  a  nominal  _ volt,  _ hertz  power 

source  having  characteristics  as  described  in _ . 

3. 3.2.4  Survivability/Vulnerability. 

‘  section  ihall  contain  Aubpariagriaph  S/V  K&quuAmentA  which  one  denlved 
inom  the.  overtoil  weapon  4 yitem  S/V  riequlaementi .  J 

3. 3. 2. 5  Maintainability  (Qualitative) . 

(Thli  section  ihall  contain  4 ubpartagriaph  maintainability  A.equlAe/nent&  which 
arie  denlved  ^fiom  the  overtoil  weapon  &y6tem  maintainability  nequlriementt> .) 
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3.4  Design  and  Construction. 

(Th- lb  bection  bhall  include.  bubpaxagxaphb  to  bpeci^y  minimum  nequixementb  that 
axe  not  contxolied  by  pexfioxmance  chaxactexibticb  on.  inten.la.ee  xequixementb . 

They  bhall  include  applicable  debign  btandaxdbj  xequixementb  govenning  the  ube 
on.  selection  o&  matexialb,  pxocebbeb,  and  paxtb;  intexchangeability  xequixe- 
menti,  Aafiety  xequixementb ,  etc.  To  the  maximum  extent  pobbible,  thebe  xequixe¬ 
mentb  6 hall  be  bpeci&ied  by  nie^exence  to  ebtablibhed  militaxy  btandaxdb  and 
bpeci^icationb . ) 


i 
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4.  QUALITY  ASSURANCE 


4.1  Ve ri f icat ion  Requirement s .  This  section  describes  the  methods  for 
verification  of  compliance  with  the  performance  and  design  requirements  of 
Section  3.  The  verification  methods  consist  of  inspection,  analysis,  demon¬ 
stration,  and  test  which  are  applied  as  appropriate  in  the  qualification  of 
the  onboard  test  system.  A  cross  reference  between  the  requirements  of  Section 
3  and  the  methods  of  verification  for  these  requirements  is  provided  in  Table 
I. 


4.1.1  Responsibility  for  Test.  Unless  otherwise  specified,  the  inspections, 
analyses,  and  testing  specified  herein  shall  be  the  responsibility  of  the  prime 
contractor. 


4.1.2  Air  Force  Approval.  The  procuring  activity  shall  have  the  option  to 
approve  all  analyses  and  testing  required  for  verification  of  compliance  with 
Section  3  requirements  including  the  methods,  procedures,  conditions,  limits, 
and  results  of  each  verification  requirement. 


4.1.3  Inspections 

4. 1.3.1  Volune.  Compliance  with  the  volume  requirements  of  paragraph  3. 3. 2. 2 
shall  be  verified  by  inspection.  (3.3. 2.2.) 

4.1.4  Analyses 

4. 1.4.1  Interfaces.  Compliance  with  interface  requirements  shall  be  verified 
by  a  review  of  engineering  drawings,  wiring  diagrams,  and  schematics  during 
design  reviews  (3. 2. 2.1,  3. 2. 2. 2,  3.2.4). 
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4. 1.4. 2  Electrical  Power  Requirements.  Compliance  with  electrical  power 
requirements  shall  be  verified  by  analysis  for  voltage  and  frequency  charac¬ 
teristics  and  normal  electrical  system  operation  transient  surge  voltage  as 

specified  in _ .  Where  deemed  more  feasible,  the  contractor  may  substitute 

test  for  any  portion  of  the  analysis  or  perform  tests  to  support  any  part  of 
the  analysis  (3. 3. 2. 3). 

4.1.4. 3  Performance .  Compliance  with  the  onboard  test  system  performance 
requirements  shall  be  verified  by  analysis  of  design  and  test  data  as  follows: 

A.  Detection  Assurance  -  Compliance  with  the  detection  assurance  require¬ 
ment  shall  be  verified  by  analysis  of  design  and  extrapolation  of  the 
onboard  test  system  outputs  during  ground  and  in-flight  tests 

(3.3. 1.1) . 

B.  Isolation  Certainty  -  Compliance  with  isolation  certainty  require¬ 
ments  shall  be  verified  by  analysis  of  design  and  extrapolation  of 
the  onboard  test  system  outputs  during  ground  and  in-flight  tests 

(3. 3.1. 2) . 

C.  Availability  -  Compliance  with  the  availability  requirement  shall 
be  verified  by  analysis  of  design  (3. 3. 1.3). 

D.  Reliability  -  Compliance  with  the  reliability  requirement  shall  be 
verified  by  analysis  of  design  (3. 3. 1.4). 

E.  Maintainability  (Quantitative)  -  Compliance  with  the  quantitative 
maintainability  requirement  shall  be  verified  by  analysis  of  design 

(3.3. 1.5) . 

F.  False  Indication  Rate  -  Compliance  with  the  false  indication  rate 
requirement  shall  be  verified  by  analysis  of  design  and  extrapolation 
of  the  onboard  test  system  outputs  during  ground  and  in-flight  test 

(3.3. 1.6) . 

G.  Automat icity  -  Compliance  with  the  requirement  for  automaticity 
shall  be  verified  by  analysis  of  design  (3. 3. 1.7). 
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H.  Radiation  Silence  -  Compliance  with  the  requirement  for  radiation 
silence  shall  be  verified  by  analysis  of  design  (3. 3.1.8). 

I.  Self-Test.  Compliance  with  the  requirement  that  the  onboard  test 
system  be  capable  of  automatically  performing  self-test  shall  be 
verified  by  analysis  of  self-test  control  logic  design  and  test 
data  (3. 3. 1.9). 

J.  Fail  Safe  -  Compliance  with  the  requirement  that  the  onboard  test 
system  cause  no  degradation  of  the  operational  performance  of  weapon 
system  systems,  subsystems,  or  equipment  during  onboard  test  system 
failure  shall  be  verified  by  analysis  of  control  and  output  logic 
design  and  test  data  (3.3.1.10). 

K.  Test  Techniques.  Compliance  with  test  technique  requirements  shall 
be  verified  by  analysis  of  the  onboard  test  system  test  requirements 
implementation  design  (3.3.1.12). 

4. 1.4.4  Survivability/Vulnerability .  Compliance  with  the  survivability/ 
vulnerability  requirements  shall  be  verified  by  analysis  as  specified  in 
_  (3.3.2. 4). 

4. 1.4. 5  Maintainability  (Qualitative) .  Compliance  with  the  qualitative 
maintainability  requirements  shall  be  verified  by  analysis  of  maintenance 
engineering  data  and  applicable  test  data  (3. 3. 2. S''. 

4.1.5  Tests 


4. 1.5.1  Off -Aircraft.  Acceptance  testing  shall  be  performed  by  the  supplier (s) 
of  the  onboard  test  system  (or  portions  thereof  as  applicable),  prior  to  delivery 
to  the  prime  contractor,  to  verify  that  the  action  or  operation  of  the  equipment 
is  in  compliance  with  specific  quantitative  requirements  under  specific  conditions. 
Artificially  induced  signals,  loads,  operating  modes,  and  environments  may  be 
utilized  to  simulate  specified  conditions  (3. 2. 3.1,  3. 2. 3. 2,  3. 3.1.1,  3. 3. 1.2, 

3. 3.1.6,  3. 3. 1.9,  3.3.1.10,  3.3.1.11,  3. 3.2.3,  3.4). 
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4. 1.5. 1.2  Prequalification  Tests.  The  onboard  test  system  shall  be  tested 
as  a  system  to  verify  compliance  with  the  requirement  that  it  detect  and 
display  tested  weapon  system  systems,  subsystems,  and  equipment  functional 
performance,  and  identify  and  fault  isolate  malfunctions  in  accordance  with 
specification  requirements  in  all  modes  of  operation.  The  test  shall  be 
conducted  on  at  least  the  major  subsystem  level  for  all  tested  weapon  system 
subsystems.  The  test  shall  utilize  a  series  of  controlled  Air  Force  approved 
simulated  failures  and  artificially  induced  performance  degradations  and  utilize 
system  or  subsystem  hot  mockups  or  system  simulators.  The  test  shall  be  per¬ 
formed  on  the  complete  set  of  onboard  test  system  computer  programs  to  the 
maximum  extent  possibJ 3  (3. 3.1.1,  3. 3. 1.2,  3. 3. 1.6,  3. 3. 1.9,  3.3.1.10,  3.3.1.11). 

4. 1.5. 2  On -Aircraft .  The  following  tests  are  to  be  conducted  on  the  onboard 
test  system  after  installation  in  the  weapon  system. 

4. 1.5. 2.1  Ground  Tests.  Tests  shall  be  conducted  to  verify  compliance  with 
design  requirements  for  the  onboard  test  system  ground  modes  of  operation 
(3.3.1. 1,  3.3.1. 2,  3.3.1. 6,  3.3. 1.9). 

4. 1.5. 2. 2  Flight  Tests.  Tests  shall  be  conducted  to  verify  compliance  with 
design  requirements  for  the  onboard  test  system  in-flight  performance  and 
fault  isolation  modes  of  operation  for  all  performance  envelopes  of  the  weapon 
system.  Natural,  rather  than  induced,  failures  shall  be  used  to  evaluate  the 
effectiveness  of  the  in-flight  detection  and  isolation  modes.  During  flight 
test,  ground  and  flight  test  instrumentation  data  shall  be  used  to  evaluate 
the  effectiveness  of  the  onboard  test  system  in  detecting  out -of -tolerance 
conditions.  Preflight  and  postflight  operational  checkouts  of  the  weapon  system 
systems,  subsystems,  and  equipment  shall  be  included  to  demonstrate  failure 
isolation  capabilities  of  the  onboard  test  system.  The  tests  shall  demonstrate 
the  ability  of  the  onboard  test  system  to  determine  the  output  weapon  system 
status  and  isolate  faults  in  accordance  with  Section  3  requirements  (3. 3. 1.1, 
3.3.1. 2,  3. 3.1. 6,  3.3.1. 9). 
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TABLE  1 

VERIFICATION  CROSS  REFERENCE 


REQUIREMENT 

REQUIREMENTS  AND  VERIFICATION 

INFORMATION 

REFERENCE 

PARAGRAPH 

PARAGRAPH 

TITLE 

(TP/PS  NO. ) 

3 

N/A 

3.1 

N/A 

3.2 

N/A 

3.2.1 

N/A 

3.2.2 

N/A 

3.2. 2.1 

4. 1.4.1 

Interfaces 

3. 2. 2. 2 

4. 1.4.1 

Interfaces 

3.2.3 

N/A 

3.2. 3.1 

4. 1.5. 1.1 

Acceptance  Tests 

3. 2. 3. 2 

4. 1.5. 1.1 

Acceptance  Tests 

3. 2. 4 

4. 1.4.1 

Interfaces 

3.3 

N/A 

3.3.1 

N/A 

3. 3. 1.1 

4. 1.4. 3 

Performance 

4.1. 5.1.1 

Acceptance  Tests 

4. 1.5. 1.2 

Pre-Qualification  Tests 

4. 1.5. 2.1 

Grouid  Tests 

4. 1.5. 2. 2 

Flight  Tests 

3.  3. 1. 2 

4. 1.4. 3 

Performance 

4. 1.5. 1.1 

Acceptance  Tests 

4. 1.5. 1.2 

Pre-Qualification  Tests 

4. 1.5. 2.1 

Grouid  Tests 

4. 1.5. 2. 2 

Flight  Tests 

3.  3. 1.  3 

4. 1.4.3 

Performance 

3.  3. 1. 4 

4. 1.4. 3 

Performance 

3.  3. 1. 5 

4. 1.4. 3 

Performance 

3.  3. 1.6 

4. 1.4.3 

Performance 

4. 1.5. 1.1 

Acceptance  Tests 

4. 1.5. 1.2 

Pre-Qualification  Tests 

4. 1.5. 2.1 

Ground  Tests 

4. 1.5. 2. 2 

Flight  Tests 

3.  3. 1. 7 

4. 1.4. 3 

Performance 

3.  3. 1. 8 

4. 1.4. 3 

Performance 

3. 3. 1.9 

4.1.4. 3 

Performance 

4. 1.5. 1.1 

Acceptance  Tests 

4. 1.5. 1.2 

Pre-Qualification  Tests 

4. 1.5. 2.1 

Ground  Tests 

4.1. 5.2.2 

Flight  Tests 
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TABLE  I 

VERIFICATION  CROSS  REFERENCE 

REQUIREMENTS  AND  VERIFICATION  INFORMATION 

REQUIREMENT  REFERENCE 


PARAGRAPH 

PARAGRAPH 

TITLE  (TP/PS  NO.) 

3.3.1.10 

4. 1.4. 3 

Performance 

4. 1.5. 1.1 

Acceptance  Tests 

4. 1.5. 1.2 

Pre-Qualification  Tests 

3.3.1.11 

4. 1.5. 1.1 

Acceptance  Tests 

4. 1.5. 1.2 

Pre -Qualification  Tests 

3.3.1.12 

4. 1.4. 3 

Performance 

3.3.2 

N/A 

3.3.2. 1 

N/A 

3. 3. 2. 2 

4.1. 3.1 

Volume 

3. 3.2. 3 

4. 1.4. 2 

Electrical  Power  Requirements 

4. 1.5.1. 

Acceptance  Tests 

3. 3.2.4 

4. 1.4. 4 

Survivability /Vulnerability 

3. 3. 2. 5 

4.1.4. 5 

Maintainability  (Qualitative) 

3.4 

4. 1.5. 1.1 

Acceptance  Tests 
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APPENDIX  B 


PROCUREMENT  SPECIFICATION 
FORMAT  FOR  CNBOARD 
TEST  SYSTEM  REQUIREMENTS 

This  appendix  is  an  example  of  the  type  of  onboard  test  system  (OBTS) 
requirements  that  should  be  included  in  the  procurement  specification  of  the 
systems  under  test.  Paragraph  headings  preceeding  the  OBTS  requirements  are 
included  to  give  greater  visibility  to  the  context  of  these  requirements.  The 
name  of  the  system  under  test  is  to  be  inserted  in  the  space  coded 

1.  SCOPE 

2.  APPLICABLE  DOCUMENTS 

3.  REQUIREMENTS 

3.1  Item  Definition 

3.1.1  It  an  Diagrams 

3.1.2  Interface  Definition 

3. 1.2.1  Aircraft  Subsystem  Interface 

3. 1.2. 1.1  Electrical  Power  Subsystem 

3. 1.2. 1.2  Environmental  Control  Subsystem 

3. 1.2. 1.3  Hydraulic  Power  Subsystem 
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3. 1.2. 1.4  Onboard  Test  System  (OBTS)  Interface 

The  *  shall  interface  with  the  OBTS  and  provide  test  signals  to  the 
OBTS  as  necessary  to  satisfy  the  performance  requirements  of  paragraph  3. 2. 1.4. 


3.1. 2. 1.4.1  Test  Signal  Interface  Requirements 

The  test  signals  shall  be  conditioned,  buffered,  and  scaled  in  accordance 
with  the  following  interface  requirements: 
a.  Analog  (  *  Output  to  OBTS) 

(1)  Vc  tage  _ to  plus  or  minus  _ volts  dc 


(2)  Impedance 


(3) 

(4) 


Frequency 

Accuracy 


(differential) 

_ megohm  minimum  (differential) 

at  the  specified  voltage 
DC  to  _ Hz 

_ percent  of-  full  scale 


NOTE:  All  analog  signals  transmitted  to  OBTS  shall  be  scaled,  con¬ 
ditioned,  demodulated,  and/or  converted  to  a  dc  analog  volt¬ 
age  by  the  *  . 


b. 


Discrete  (  *  Output  to  OBTS) 

(1)  Logic  "1"  Plus 

volt 


volts  dc  plus  or  minus 


(2)  Logic  "0"  _ volts  dc  plus  or  minus  _ _  volt 

(3)  Current  capability  _ milliamperes  current  minimum  at 

plus  _ volts 

c.  Discrete  (OBTS  Input  to  the  *) 

(1)  Logic  ’l”  Plus  _ volts  dc  to  plus  _ volts 

dc  (differential) 

(2)  Logic  "0"  _ volts  dc  to  plus  or  minus  _ 

volts  dc  (differential) 

(3)  Impedance  _ ohms  minimum  (differential)  for 

either  logic  "l"  or  logic  "0"  input 
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d.  Digital  Data  (  *  Output  to  OBTS)  ** 


CD 

Logic  "l" 

Plus  volts  dc  plus 

or  minus 

volt 

(2) 

Dead  time 

Zero  plus  or  minus 

volt 

(3) 

Logic  "0” 

volts  dc  plus  or  minus  volt 

(4) 

Word  length 

-bit  word  plus  one 

parity  bit 

(5) 

Impedance 

ohms  plus  or  minus 

percent 

(6) 

Rise  and  fall  time 

plus  or  minus 

nanoseconds 

(7) 

Code 

(8) 

Bit  rate 

plus  or  minus 

megabit  per 

second 

Digital  Address  COBTS  Input  to  the  *1  ** 

(D 

Logic  "1" 

Plus  volts  dc  to 

_  volts  dc 

(2) 

Dead  time 

Zero  volts  to  plus 

volts 

(3) 

Logic  "0" 

_  volts  dc  to  minus 

_____  volts  dc 

(4) 

Word  length 

_  -bit  word  plus  one 

parity  bit 

(5) 

Impedance 

ohms  plus  or  minus 

percent 

(6) 

Rise  and  fall  time 

plus  or  minus 

nanoseconds 

(7) 

Code 

(8) 

Bit  rate 

plus  or  minus 

megabit  per 

second 

**N0TE : 

OBTS  will  send  a 

_  -bit  address  (  -bit  word  plus  one 

parity  bit)  to  the 

*  .  After  the  last  bit 

of  the  address 

word  from  OBTS  has  been  received,  the  _ shall  begin  trans¬ 
mitting  the _  -bit  data  ( _  -bit  word  plus  one  parity 

bit)  to  OBTS  within  _ microseconds. 
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3. 1.2. 1.4. 2  OBTS  Supplemental  Signals 

The  selected  signals  listed  in  Table  A  shall  be  provided  by  the  *  for 
OBTS  usage.  These  signals  shall  not  duplicate  signals  required  for  compliance 
with  paragraph  3. 2. 1.4.  The  signal  interface  with  the  OBTS  shall  conform  to 
paragraphs  3. 1.2. 1.4.1,  3. 4. 1.1,  and  3. 4. 1.3. 

TABLE  A 

OBTS  SUPPLEMENTAL  SIGNALS 

Item  Signal  Name  Signal  Type 

A 
B 
C 

3.2  Characteristics 


3.2.1  Performance 


3. 2. 1.1  Operating  Modes 

3. 2. 1.2  Accuracies 

3. 2. 1.3  Operating  Time 

3. 2. 1.4  OBTS  Requirements 

The _ shall  be  capable  of  being  tested  by  the  OBTS  in  all  modes  of 

operation  during  flight  or  on  the  ground  without  being  supplemented  by  TMDE. 
The _ shall  have  provisions  for  verification  of  acceptable  performance, 
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detection  of  failures,  identification  of  affected  functions,  and  isolation  of 
failures  to  the  LRU  level.  Failure  shall  be  defined  as  any  condition  wherein 
the  performance  requirements  of  this  specification  are  not  fulfilled. 

3. 2. 1.4.1  Performance  Test 


3. 2. 1.4. 1.1  Flight  Configuration  Test 

A  continuous  flight  configuration  test  capability  shall  be  provided  for 
automatic  real-time  determination,  by  the  OBTS,  of  *  performance  in  all  modes 
of  operation  during  aircraft  start-up,  taxi,  flight,  landing,  and  shut-down. 

The  flight  configuration  test  capability  shall  be  designed  for  detection  of 
failures  and  identification  of  affected  modes  and  functions  by  the  OBTS. 

In  no  instance  shall  this  test  interrupt  normal  *  operation,  cause 
movement  of  aircraft  flight  control  surfaces,  cause  erroneous  reading  of  cock¬ 
pit  indications,  or  cause  any  other  unconmanded  operation  of  aircraft  systems. 
The  flight  configuration  test  capability  shall  provide  to  be  determined  (TBD) 
percent  assurance  v. f  detecting _ failures,  based  on  failure  rate,  and  cor¬ 

rectly  indicating  effects  on  performance.  Refer  to  Appendix  1  for  percent 

detection  assurance  calculation  procedure.  All  _ failure  modes  affecting 

flight  safety  shall  be  detected. 

3. 2. 1.4. 1.2  Ground  Operational  Readiness  Test 

The  operationally  acceptable  status  of  *  shall  be  verified  by  the  OBTS 
while  the  aircraft  is  on  the  ground.  This  operator  selected  test  shall  verify 
the  proper  operation  of  all  normal,  and  alternate,  redundant,  and  standby  modes 
of  *  operation.  Maximum  use  shall  be  made  of  test  provisions  and  test  logic 
established  for  the  flight  configuration  tests,  tests  that  simulate  in-flight 
operating  conditions,  and  tests  that  utilize  OBTS  stimuli  to  exercise  redundant 
and  flight  critical  *  modes.  The  ground  operational  test  capability  shall 


provide  TBD  percent  assurance  of  detecting  *  failures,  based  on  failure  rate. 
Refer  to  Appendix  1  for  percent  detection  assurance  calculation  procedure.  All 

*  failure  modes  affecting  flight  safety  shall  be  detected. 

3. 2. 1.4. 2  Fault  Isolation  Tests 

The  *  shall  provide  the  capability  for  the  OBTS  to  isolate  detected 
failures  to  the  malfunctioning  LRU  with  a  TBD  percent  certainty.  Refer  to 
Appendix  1  for  percent  certainty  calculation  procedure. 

The  LRU  isolation  shall  be  accomplished  by  the  flight  configuration  and 
ground  operational  readiness  tests. 

3.3  Design  and  Construction 

3.4  Major  Components  Characteristics 

3.4.1  OBTS  Test  Provisions 

The  OBTS  test  provisions  of  the  _ shall  include  access  to  those  indi¬ 

cating  and/or  operational  signals  which  will  be  used  by  the  OBTS  for  test 
data  acquisition,  test  control,  performance  monitoring,  and  failure  evaluation. 
The  OBTS  test  provisions  shall  make  maximum  use  of  dynamic  operational  signals 
within  the  *  for  performance  monitoring  and  fault  isolation  and  shall  not 
employ  hardware  for  exclusive  use  by  the  OBTS  unless  necessary  to  satisfy  test 
requirements . 

3.4. 1.1  Fail-Safe  Design 

Failure  of _ test  provisions  shall  not  cause  failure  or  degradation  of 

*  operational  performance.  An  abnormal  OBTS  interface  condition  caused  by 

interfacing  OBTS  equipment  failure  shall  not  cause  failure  or  degradation  of 
_* _ operational  performance. 
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3. 4. 1.2  False  Indications 


The  design  of  the _ *_  test  provisions  shall  be  such  that  false  indications 

are  minimized.  A  false  indication  is  defined  as  an  indication  by  the  OBTS  of 
a  failure  of  the  *  when,  in  fact,  no  failure  exists;  or  the  absence  of  an 
indication  by  the  OBTS  of  a  detectable  failure  of  the  *  when  the  failure 
exists . 

3.4.1. 3  Test  Provision  Self-Test 

The  design  of  the  _ test  provisions  shall  be  such  that  TBD  percent  _ 

test  provision  failure  rate  shall  be  detectable  by  the  OBTS  and  shall  be  distin¬ 
guishable  from  actual  *  failures. 

4.  QUALITY  ASSURANCE  PROVISIONS 

4. 1  Verification  Requirements 

Verification  methods  that  are  applicable  to  preliminary  qualification, 
formal  qualification,  and  acceptance  of  the  *  are  identified  in  Table  B. 

The  methods  are  not  listed  in  the  sequence  of  performance. 

4.1.1  Qualification 

4.1.2  Acceptance 

4.1.3  General  Test  Requirements 

4.2  Verification  Methods 

Verification  methods  consist  of  inspection,  analysis,  demonstration,  and 
test.  (Refer  to  Section  6  for  definitions.)  For  information  purposes,  a  cross 
reference  between  Section  3  paragraphs  and  4.2  subparagraphs  is  contained  in 

6.3 
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TABLE  B 


VERIFICATION  REQUIREMENTS 


Paragraph 

Verification  Method 

Prequal 

Formal  Qual 

Acceptance 

4. 2. 2. 5 

OBTS  Analysis 

X 

4. 2. 4. 1.2.1 

OBTS  Interface  and 
Performance  Verification 

X 

X 

X 

4. 2. 4. 1.2. 1.1 

Interface  Verification 

X 

X 

X 

4. 2. 4. 1.2. 1.2 

Performance  Verification 

X 
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4.2.1  Inspections 


4.2.2  Analyses 

Requirements  to  be  verified  by  analysis  including  the  following: 


4. 2. 2.1  System  Safety 


4. 2. 2. 2  Service  Life 


4. 2. 2. 3  Reliability 


4. 2. 2.4  Maintainability 

4.2.2.5  OBTS 

The  following  OBTS  performance  and  design  capabilities  of  the _ shall 

be  verified  by  analysis. 

A.  Flight  configuration  test  detection  assurance. 

B.  Ground  operational  readiness  test  detection  assurance. 

C.  Detection  capability  of  failures  affecting  flight  safety. 

D.  LRU  isolation  certainty. 

E.  Fail-safe  design  capability. 

F.  Test  provisions  self-test  capability. 

G.  Interface  compatibility 

H.  Justification  for  selection  of  test  signals,  transducers,  and  sensors. 

4. 2. 2.6  Survivability/Vulnerability 


4. 2. 2. 7  Electromagnetic  Interference  and  Compatibility 
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4.2.3  Demonstrations 


4.2.4  Tests 

Verification  tests  consist  of  performance  and  design  verification  tests 
and  environmental  tests. 

4.2. 4.1  Performance  and  Design  Verification  Tests 

4. 2. 4. 1.1  Performance  Record  Test 

4. 2. 4. 1.2  Subsystem  Tests 

Tests  shall  be  conducted  to  demonstrate  functional  operation  and  performance 
of  the  complete  subsystem.  Input  power  and  output  load  devices  shall  be  used  to 
simulate  the  comparable  aircraft  interfaces. 

4. 2. 4. 1.2.1  OBTS  Interface  and  Performance  Verification 

Tests  shall  be  conducted  on  the  *  to  verify  compliance  with  the  OBTS 
requirements  of  paragraph  3.  These  tests  shall  include,  but  shall  not  be 
restricted  to  the  following: 

4. 2. 4. 1.2. 1.1  Interface  Verification 

The  OBTS  interface  requirements  shall  be  verified  in  all  modes  of  * 
operation. 


4. 2.4. 1.2. 1.2  Performance  Verification 

Tests  shall  be  conducted  on  the  *  to  verify  the  detection  assurance, 
isolation  certainty,  fail-safe  design,  and  test  provision  self-test  capability 
of  the  OBTS  test  signals.  These  tests  shall  consist  of  simulating  malfunction 


conditions  and  verifying  that  the  OBTS  signals  and  defined  logic  produce  the 
required  performance.  The  number  of  malfunctions  simulated  shall  include  all 
safety-of-flight  and  mission  critical  *  failure  modes  plus  a  minimum  of  TBD 
percent  of  the  remaining  *  failure  modes.  Selection  of  all  simulated  mal¬ 
functions  shall  be  subject  to  contractor  approval. 

5.  PREPARATION  FOR  DELIVERY 

6.  NOTES 

6.1  Definitions 


6.2  Preferred  Parts  List 


6.3  Verification  Cross  Reference 

Table  C  identifies  each  requirement  in  Section  3  and  correlates  the  Section 
4  paragraphs  that  verify  it. 
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TABLE  C 


VERIFICATION  CROSS  REFERENCE 


Section  3 


3.1.2.: 


3.1.2.: 


3.1. 2. 1.4. 2 


3. 2. 1.4. 1.2 


3. 2. 1.4. 2 


Section  4 


.2.1.1 
.2.2.5 
.2. 4. 1.2.1 
.2. 4. 1.2. 1.1 
.2.1.1 
.2.2.5 
.2. 4. 1.2.1 
.2.4. 1.2. 1.1 
.2.1.1 
.2.2.5 
.2. 4. 1.2.1 
.2. 4. 1.2. 1.1 

.2.2.5 
.2. 4. 1.2.1 
.2. 4. 1.2. 1.1 
.2. 4. 1.2. 1.2 
/A 

.2.2.5 
.2. 4. 1.2.1 
.2. 4. 1.2. 1.1 
.2. 4. 1.2. 1.2 
.2.2.5 
.2. 4. 1.2.1 
.2. 4. 1.2. 1.1 
.2. 4. 1.2. 1.2 
.2.2.5 
.2. 4. 1.2.1 
.2. 4. 1.2. 1.1 
.2. 4. 1.2. 1.2 


Section  3 


Section  4 


.2.1. 

.2.2. 

.2.4. 

.2.4. 

.2.4. 

.2.1. 

.2.2. 

.2.4. 

.2.4. 

.2.4. 

.2.1. 

.2.2. 

.2.4. 

.2.4. 

.2.4. 

.2.1. 

.2.2. 

.2.4. 

.2.4. 

4.2.4. 


1 

5 

1.2.1 
1.2. 1.1 
1.2. 1.2 
1 
5 

1.2.1 
1.2. 1.1 
1.2. 1.2 
1 

5 

1.2.1 
1.2. 1.1 
1. 2.1.2 
1 
5 

1.2.1 
1.2. 1.1 
1.2. 1.2 


APPENDIX  1 


10.  OBTS  REQUIREMENTS  CALCULATION  PROCEDURE 

10.1  Scope 

This  appendix  describes  the  procedure  for  calculating  the  OBTS  detection 
assurance  and  isolation  certainty  capability  of  the  *  as  required  by  para¬ 
graph  3. 2. 1.4. 

10.2  OBTS  Requirements  Calculation  Procedures 

The  following  procedures  utilize  the  *  FMEA  data. 

10.2.1  Percent  Detection  Assurance 

The  following  method  shall  be  used  to  calculate  the  percent  detection 
assurance  capability  of  the  *  : 

Percent  detection  assurance  =  Total  failure  rate  of  detected  failure  modes  x 

Total  system  failure  rate  °* 

i=m 

IX.  ,  , 

D  =  i=l  X  100%  =  —  X  100%  =  t--  X  100% 

A,  +  A  A 

i=n  d  u 

I  X. 

1 

i=l 

Where: 

D  =  percent  detection  assurance 

X^  =  failure  rate  of  ith  failure  mode  (failures  per  million  hours) 

X,  =  failure  rate  summation  of  all  failure  modes  detected  by  the  OBTS 
a 

X^  *  failure  rate  summation  of  all  failure  modes  undetected  by  the  OBTS 

X  =  failure  rate  summation  of  all  failure  modes,  both  detected  and  un¬ 
detected 

m  *  number  of  failure  modes  detected  by  the  OBTS 
n  *  total  nunber  of  failure  modes 


V- 
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10.2.2  Percent  Isolation  Certainty 

The  following  method  shall  be  used  to  calculate  the  percent  isolation 
certainty  capability  of  the  *  : 


Percent  isolation  certainty  =  Creditable  failure  rate  for  LRU  isolation  ^ 

Total  failure  rate  of  detected  failure  modes 


j=x 

X  IX 

I  =  t—  X  1001  =  j=l 
d  i=m 

Z  X. 

l 

i=l 


X  100%  = 


j=x 

z 

3=1 


k=y 

Z 

k=l 


fAIBjk)2 


k=y 

k=lIB^k 


i=m 


E 
i=l 


X. 

l 


X  100% 


Where: 


I 


XIBjk 


x 

y 

m 


percent  isolation  certainty 
creditable  failure  for  LRU  isolation 

failure  rate  summation  of  all  failure  modes  detected  by  the  OBTS 

creditable  failure  rate  for  jth  isolation  block 

failure  rate  of  the  kth  LRU  which  contributes  to  the  failure 

rate  of  the  jth  isolation  block 

number  of  isolation  blocks 

number  of  LRU's  involved  in  an  isolation  block 

number  of  failure  modes  detected  by  the  OBTS 
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.Appendix  C 

STANDARD  SIGNAL  INTERFACE  SPECIFICATION 


This  appendix  contains  an  example  of  a  standard  signal  interface  spec¬ 
ification  as  referenced  in  paragraph  3. 2. 1.1.  (Note:  Portions  of  this  ex¬ 
ample  may  be  superceded  by  MIL-STD-1553B  and  its  Notice  One.) 

1.  SCOPE 

1.1  Scope .  This  specification  establishes  the  interface  requirements  for 

transmitting,  receiving,  and  formatting  of  applicable  data  signals  provided 
by  the  air  vehicle  electrical,  electronic,  and  military  avionics  components 
and  subsystems.  « 

1.2  Classification.  The  signal  characteristics  at  the  interface?  shall  be 
of  the  following  types: 

a.  Type  I.  Type  I  data  signals  are  unique  foi  party  line  digital  data 
transmission  equipment,  data  receiving  equipment,  and  data  format. 

A  party  line  interface  in  the  air  vehicle  is  defined  as  one  involv¬ 
ing  two-way  digital  transmission  of  data  nonsimultaneously  between 
subsystems  or  subsystem  LRU's  all  under  the  direction  of  a  controller. 
The  controller  may  be  a  computer  or  a  special-purpose  control  unit. 

b.  Type  II.  Type  II  data  signals  are  unique  for  dedicated  serial  data 
transmission  equipment,  data  receiving  equipment,  and  data  format. 

A  dedicated  serial  digital  interface  in  the  air  vehicle  is  defined 
as  one  involving  one-way  digital  transmission  of  data  between  sub¬ 
systems  or  subsystem  LRU's. 

c.  Type  III.  Type  III  data  signals  consist  of  standard,  discrete,  dc 
analog,  and  digital  signals  that  will  be  used  to  interface  with  a 
Type  I  system  or  between  subsystems  or  subsystem  LRU's  as  required 
by  the  detail  specification. 
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d.  Type  IV.  Type  IV  signals  consist  of  standard  analog  signals  that 
will  be  used  to  interface  between  subsystems  or  between  subsystem 
LRU's  as  required  by  the  detail  specification.  (Type  IV  signals 
are  not  intended  to  be  used  to  interface  between  Type  I  systems  and 
other  subsystems.) 

2.  APPLICABLE  DOCUMENTS 

2.1  Applicability.  The  following  documents  of  the  exact  issue  shown  form  a 
part  of  this  specification  to  the  extent  specified  herein.  In  the  event  of 
conflict  between  the  documents  referenced  below  and  the  contents  of  this  spec¬ 
ification,  the  contents  of  this  specification  shall  be  considered  a  super¬ 
seding  requirement.  In  the  event  of  conflict  between  this  specification  and 
the  detail  procurement  specification,  the  detail  procurement  specification 
shall  take  precedence. 

2.1.1  Government  Documents . 

SPECIFICATIONS 

Military 
MIL-C-7078B  (1) 

5  December  1967 
STANDARDS 
Military 
MIL-STD-442B 
1  December  1967 

3.  REQUIREMENTS 

3.1  Standardization.  Subsystem  signal  interfaces  shall  conform  to  the  stand¬ 
ardized  requirements  specified  herein. 


Cable,  Electric,  Aerospace  Vehicle,  General 
Specification  for 

Aerospace  Telemetry  Standards 


< 
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3.1.1  Signal  Polarity.  The  standard  signal  circuits  shall  be  protected  from 
damage  by  input  signal  polarity  reversal  and  shall  not  be  damaged  by  short  cir¬ 
cuiting  of  the  input  and  output  terminations. 

3.1.2  Data  Form.  Digital  data  shall  be  expressed  in  the  following  forms: 

a.  True  binary  form  with  negative  binary'  numbers  expressed  in  a  two's 
complement  form. 

b.  Binary-coded  decimal. 

c.  Group  of  discrete  bits  formatted  into  a  data  word.  Discrete  bits  may 
also  be  inserted  in  unused  bit  spaces  of  data  words  carrying  other 
types  of  information.  Unused  bit  positions  shall  be  transmitted  as  a 
logic  zero. 

3.1.3  Bit  Priority.  The  most  significant  bit  shall  be  transmitted  first  with 
the  less  significant  bits  following  in  descending  order  of  value.  The  number  of 
bits  required  to  define  a  quantity  shall  be  consistent  with  the  resolution  or 
accuracy  required.  In  the  event  double  precision  quantities  (information  accur¬ 
acy  or  resolution  requiring  more  than  20  bits)  are  transmitted,  the  most  signi¬ 
ficant  half  shall  be  transmitted  first,  followed  by  the  least  significant  half. 

3.2  Characteristics .  Unless  otherwise  indicated,  the  following  requirements 
are  applicable  to  both  Type  I  and  Type  II  signals. 

3.2.1  Transmission  Method. 

3. 2. 1.1  Pulse  Code  Modulation.  Data  and  synchronization  information  shall  be 
transmitted  using  pulse  code  modulation  (PCM) . 
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3. 2. 1.2  Data  Code.  The  data  code  shall  be  Manchester  11  (Bi0-L)  as  defined 
in  MIL-STD-442.  A  logic  "one"  shall  be  transmitted  as  a  dipolar  coded  signal 
10  (i.e.,  a  positive  pulse  followed  by  a  negative  pulse).  A  logic  "zero" 
shall  be  bipolar  coded  signal  01  (i.e.,  a  negative  pulse  followed  by  a  positive 
pulse).  See  Figure  1. 

3. 2. 1.3  Data  Rate.  The  data  bit  rate  shall  be  1  megabit  per  second  plus  or 
minus  0.1  percent. 

3. 2. 1.4  Data  Link  Clock.  The  data  link  clock  shall  be  generated  by  the  trans¬ 
mitting  subsystem  and  used  in  the  fabrication  of  the  Manchester  11  code  format. 
The  receiving  subsystem  shall  derive  the  clock  from  the  Manchester  11  code 
format  as  received. 

3. 2. 1.5  Message.  The  data  may  be  in  the  form  of  a  message.  If  a  message  for¬ 
mat  is  used,  the  first  word  of  each  message  shall  be  preceded  by  a  message  sync, 
and  each  subsequent  word  of  the  message  shall  be  preceded  by  a  word  sync.  The 
message  format  for  Type  I  data  signals  shall  be  as  specified  in  3.2.1.12.1. 

The  message  format  for  Type  II  data  signals  shall  be  as  specified  in  3.2.1.12.3. 

3. 2. 1.6  Message  Sync.  The  message  sync  shall  be  a  nonvalid  Manchester  code  as 
shown  in  Figure  2.  The  positive  and  negative  going  pulses  that  form  a  message 
sync  shall  be  1.5  microseconds  plus  or  minus  3  percent  wide,  respectively.  A 
Manchester  11  01  code  immediately  preceding  or  following  the  message  sync  will 
increase  the  apparent  width  of  the  affected  pulse  by  0.5  microseconds  plus  or 
minus  10  percent. 
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1  MICROSEC  ±0.1  .PERCENT  AVERAGE 


1  10 


0  0,1  1 


o  i  : 


fIMfiflILFt-::: 


1,000  NANOSEC  ±5  PERCENT 
1,000  NANOSEC  *5  PERCENT 
-  500  NANOSEC  ±10  PERCENT 


10TE  B!  PHASE  LEVEL  (MANCHESTER  11) 
"1"  REPRESENTED  BY  10 
"0"  REPRESENTED  BY  01 


FIGURE  1.  DATA  CODE 


VOLTAGE 

VOLTAGE 
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3. 2. 1.7  Data  Word  Sync.  The  data  word  sync  shall  be  a  nonvalid  Manchester 
code  as  shown  in  Figure  3.  The  negative  and  positive  going  pulses  that  form 
a  data  word  sync  shall  each  be  1.5  microseconds  plus  or  minus  3  percent  wide, 
respectively.  A  Manchester  11  10  code  immediately  preceeding  or  following 
the  data  word  sync  will  increase  the  apparent  width  of  the  affected  pulse  by 
0.5  microsecond  plus  or  minus  10  percent. 

3. 2. 1.8  Word  Size.  The  word  size  shall  be  21  bits  plus  sync  as  shown  in 
Figure  4. 

3. 2. 1.9  Word  Format.  The  word  format  (bit  definition)  shall  be  specified 
in  the  detail  specification. 

3.2.1.10  Number  of  Words.  The  number  of  words  in  a  message  shall  be  as 
specified  in  the  detail  specification. 

3.2.1.11  Parity  Bit.  Each  word  shall  contain  a  parity  bit.  During  trans¬ 
mission,  the  parity  bit  shall  be  assigned  a  value  so  the  total  number  of 
"ones"  in  the  word  is  odd.  During  reception,  the  parity  shall  be  checked 
by  determining  whether  or  not  the  received  word  contains  an  odd  number  of 
"one". 


3.2.1.12  Message  Format. 

3.2.1.12J  Message  Format,  Type  I.  The  Type  I  message  format  shall  be  as 
shown  in  Figure  4.  The  first  word  will  be  a  conmand  word  followed  by  data 
words.  The  format  of  the  command  and  data  words  (bit  designation)  shall  be 
as  specified  in  the  detail  specification. 


figure  2.  Message  Sync  -  Nonvalid  Manchester  Code 


Figure  3.  Word  Sync  -  Nonvalid  Manchester  Code 
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Figure  A.  Type  I  Message  Format  Two-Way  Party  Line 


3.2.1.12.2  Message  Termination,  Type  I.  When  an  output  circuit  turns  off 
(stops  transmitting  data)  there  shall  be  a  2 . 0 -microsecond  minimum  dead  time 
before  any  output  circuit  shall  be  permitted  to  tum  on  (start  transmitting 
data) . 

3.2.1.12.3  Message  Format,  Type  II.  The  Type  II  message  format  shall  be  as 
shown  in  Figure  5.  The  transmitting  subsystem  shall  transmit  message  sync 
followed  by  data  words  on  a  continuous  basis,  one  word  after  the  other,  in  a 
fixed  sequence,  until  all  data  words  have  been  transmitted.  The  above  se¬ 
quence  shall  be  repeated  continuously. 

3.2.2  Transmission  Line. 

3. 2. 2.1  Cable.  The  cable  used  to  transfer  messages  will  be  a  two-conductor, 
twisted,  single -shielded,  jacketed  cable  equivalent  to  a  twin  axial  cable 
having  71  ohms  plus  or  minus  10  percent  impedance  and  a  distributed  capac¬ 
itance  no  greater  than  50  picofarads  per  foot. 

3. 2. 2. 2  Cable  Length.  The  cable  length  may  be  up  to  300  feet  long  excluding 
the  length  of  cable  stubs  specified  in  3. 2. 3. 6.1  for  Type  I  signals.  The 
length  of  redundant  cables  carrying  redundant  data  may  vary  in  relationship 
to  each  other  as  much  as  plus  or  minus  25  percent  to  accommodate  routing 
paths. 


3. 2. 2. 3  Number  of  Cables.  The  number  of  cables  shall  be  as  specified  in  the 
detail  specification  and  shall  be  a  function  of  the  number  of  redundant  trans¬ 
mitters  and  receivers  required  by  the  subsystem  detail  specification.  A  fault 
in  a  redundant  cable  shall  not  affect  the  ability  of  the  alternate  cable  and 
associated  output  and  input  circuits  to  operate. 
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Figure  5.  Type  II  Message  F  mmt,  Dedicated 
Serlel  Digital,  One-Way 


3. 2. 2. 4  Cable  Shield  Termination.  The  cable  shield  shall  be  connected  to 


air  vehicle  ground  at  all  terminal  connector  breaks. 

3. 2. 2. 5  Cable  Termination.  The  cables  shall  be  transformer-coupled  to  all 
subsystems  as  specified  in  3.2.3.  Insulation  resistance  shall  be  no  less 
than  2  megohms. 

3. 2. 2. 6  Number  of  Terminations. 

3. 2. 2. 6.1  Number  of  Terminations,  Type  I.  For  Type  I  signals,  no  more  than 
32  transmitter-receivers  shall  be  coupled  to  the  cable. 

3. 2. 2. 6. 2  Number  of  Terminations,  Type  II.  For  Type  II  signals,  one  trans¬ 
mitter  and  no  more  than  four  receivers  will  be  coupled  to  the  cable. 

3.2.3  Output -Input  Circuits. 

3. 2. 3.1  Circuit  Configuration,  Type  I.  The  output -input  circuits  shall  con¬ 
sist  of  a  transmitter- receiver,  coup ling -transformer,  and  isolation  resistors 
as  configured  in  Figure  6.  The  isolation  resistors  may  either  be  in  the  LRU 
or  external  to  the  LRU  with  an  external  transformer  as  specified  in  the  detail 
specification. 

3. 2. 3. 2  Circuit  Configuration,  Type  II.  The  output  circuit  shall  consist  of 
a  transmitter  and  coupling-transformer.  The  input  circuit  shall  consist  of 

a  receiver  and  coupling-transformer  (see  Figure  7). 

3. 2. 3. 3  Number  of  Output -Input  Circuits  (Redundancy).  The  number  of  output- 
input  circuits  in  a  subsystem  shall  be  in  accordance  with  the  detail  spec¬ 
ification.  There  shall  be  one  output-input  circuit  for  each  cable  specified 
in  the  detail  specification. 


REDUNDANT  TRANSHISS  I  OH  LINE 


OUTPUT/ I NPUT  CIRCUIT  REDUN  OUT/IN  CIRCUIT  OUTPUT/INPUT  CIRCUIT 


Figure  7.  Type  II  Dedicated  Serial  Digital 
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3. 2. 3. 4  Fault  Protection  (Redundancy).  The  redundant  output-input  circuits 
shall  be  isolated  from  each  other  so  that  a  single  fault  (short  to  ground, 
voltage,  or  open)  shall  not  affect  the  ability  of  the  alternate  output -input 
circuits  to  transmit  or  receive  data.  The  output -input  circuits  shall  not 
be  damaged  by  opens,  shorts  to  ground,  shorts  to  voltage  sources  of  zero  to 
plus  or  minus  50  volts  peak,  line-to-ground,  or  short  to  a  voltage  source  of 
zero  to  plus  or  minus  50  volts  peak,  zero  to  50 -micro second  pulse,  line-to- 
line. 

3. 2. 3. 5  Fault  Isolation,  Type  I.  An  isolation  resistor  shall  be  provided 
with  a  value  of  54  ohms  plus  or  minus  5  percent  in  series  with  each  output 
lead  of  the  Type  I  signal  output-input  circuit  coupling -transformer.  The 
impedance  reflected  on  the  cable  shall  be  no  less  than  103  ohms  for  any  fail¬ 
ure  of  the  coupling-transformer  or  transmitter-receiver  circuit. 

3. 2. 3. 6  Output  Circuit  Characteristics. 

3. 2. 3. 6.1  Ouput  Circuit  Power,  Type  1.  The  Type  I  signal  output  circuit 
shall  be  capable  of  driving  the  cable  specified  in  3. 2. 2. 2  and  no  less  than 
31  output-input  circuits,  as  specified  herein,  each  attached  to  the  cable  by 
means  of  a  cable  stub  not  longer  than  20  feet  in  length.  The  output  circuits 
shall  maintain  the  specified  operation  except  for  a  25  percent  maximum  re¬ 
duction  of  the  data  link  signal  amplitude  in  the  event  that  one  of  the  31 
output -input  circuits  has  a  fault  that  causes  it  to  reflect  the  fault  imped¬ 
ance  specified  in  3. 2. 3. 5.  The  signal  output  voltage  on  the  cable  shall  be 

a  nominal  plus  or  minus  3.0  volts  peak  line-to-line. 

3. 2. 3. 6. 2  Output  Circuit  Power,  Type  II.  Type  II  signal  output  circuit 
shall  be  capable  of  driving  the  cable  specified  in  3. 2. 2.1  and  no  less  than 
four  Type  II  signal  input  circuits  attached  to  the  cable.  The  signal  output 
voltage  on  the  cable  shall  be  nominal  plus  or  minus  3.0  volts  peak  line-to-line. 
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3. 2. 3.6. 3  Output  Circuit  Impedance,  Type  I.  Not  applicable. 

3. 2. 3.6.4  Output  Circuit  Impedance,  Type  II.  The  Type  II  signal  output  cir¬ 
cuit  transmitting  impedance  shall  be  71  ohms  plus  or  minus  10  percent  reflec¬ 
ted  on  the  cable. 

3.2. 3.6.5  Output  Circuit  Voltage,  Type  I.  The  Type  I  signal  output  circuit 
voltage  shall  be  plus  2.7  to  plus  3.6  volts  and  minus  2.7  to  minus  3.6  volts 
peak  line-to-line  As  measured  when  the  isolation  resistors  specified  in 

3. 2. 3. 5  are  terminated  into  a  35.0-ohm  plus  or  minus  1  percent  resistor. 

3. 2. 3. 6. 6  Output  Circuit  Voltage,  Type  II.  The  Type  II  signal  output  cir¬ 
cuit  voltage  shall  be  plus  2.7  to  plus  3.6  volts  or  minus  2.7  to  minus  3.6 
volts  peak  line-to-line  reflected  on  the  cable. 

3. 2. 3. 6. 7  Output  Waveform.  The  output  circuit  waveforms  shall  be  bipolar 
pulses.  The  width  of  the  pulses  shall  be  as  shown  in  Figure  1,2,  and  3 
when  measured  at  the  zero  crossover.  The  rise  and  fall  shall  be  150  plus 
or  minus  50  nanoseconds  when  measured  at  10  percent  and  90  percent  of  the 
nominal  minus  3-  and  plus  3-volt  limits.  In  the  case  of  redundant  output 
circuits  that  transmit  concurrently,  data  time  differential  between  iden¬ 
tical  data  bits  being  transferred  on  the  individual  cables  shall  be  no 
greater  than  0.1  microsecond.  This  delay  time  shall  be  measured  at  the 

50  percent  point  of  the  applicable  bit  rise  and  fall  time  transition. 

3. 2. 3. 6. 8  Output  Waveform  Distortion.  Any  distortion  of  the  waveform  by 
the  output  circuit  including  (but  not  limited  to)  overshoot,  ringing,  fold- 
over,  or  zero  crossover  distortion  shall  not  exceed  300  millivolts  peak-to- 
peak,  line-to-line. 
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3. 2. 3.6.9  Transmitter  Output  Noise  (Off  State) .  Any  transmitter  output 
noise  when  in  the  off  state  shall  be  no  greater  than  50  millivolts  peak- 
to-peak,  line-to-line. 

3.2.3.6.10  Transmitter  Off  Impedance.  When  not  transmitting  or  when  power 
is  removed,  the  transmitter  impedance  shall  be  no  less  than  6,800  ohms  line- 
to-line  when  measured  with  plus  or  minus  6  volts  peak,  line-to-line  applied 
to  the  output  circuit  terminations. 

3. 2. 3. 7  Input  Circuit  Characteristics. 

3. 2. 3. 7.1  Input  Circuit  Compatibility.  The  input  circuit  shall  be  compatible 
with  the  incoming  signals  specified  herein  and  shall  accept  waveforms  varying 
from  a  square  wave  to  a  sine  wave. 

3. 2. 3. 7. 2  Input  Circuit  Noise  Rejection.  The  receiver  shall  detect  data  and 
sync  signals  specified  herein  that  have  a  signal -to -noise  ratio  (S+N/N)  RMS 
of  plus  14  db  with  a  probability  of  bit  error  of  better  than  one  part  in  107 
prior  to  the  data  validation  checks  (3. 2. 3. 8).  The  signal -to-noise  ratio 
shall  be  determined  with  1.5  volt  peak,  line-to-line  sync  and  data  signals 

in  a  message  form  as  specified  herein  and  white  gaussian  noise  distributed 
over  the  band  of  1,000  Hz  to  4.0  Miz,  The  input  circuit  shall  reject  all 
noise  up  to  plus  or  minus  6  volts  peak,  line-to-line,  below  1,000  Hz  and 
above  4.0  Miz. 

3.2.3. 7.3  Input  Circuit  Common  Mode  Rejection.  Signals  from  dc  to  2.0  Miz 
with  amplitudes  up  to  plus  or  minus  50  volts  peak,  line-to-ground,  applied 
to  both  the  input  circuit  terminals  that  are  connected  together  shall  not 
cause  the  receiver  to  operate  (i.e.,  the  signal  received  by  the  receiver 
shall  be  below  the  threshold  specified  in  3. 2. 3. 7. 4). 
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3. 2. 3. 7.4  Receiver  Input  Sensitivity.  The  receiver  shall  respond  with  an 
input  signal  amplitude  from  plus  or  minus  4.0  volts  peak,  line-to-line,  down 
to  a  threshold  level  of  plus  or  minus  0.6  volt  peak,  line-to-line.  The  receiv¬ 
er  shall  not  respond  to  input  signals  of  0.0  to  plus  or  minus  0.45  volt  peak, 
line-to-line,  the  receiver  shall  operate  as  specified  in  3. 2. 3. 7. 2  with  input 
signal  levels  of  plus  or  minus  4.0  volts  peak,  line-to-line,  down  to  plus  or 
minus  1.5  volts  peak  plus  or  minus  10  percent,  line-to-line. 

3. 2. 3. 7. 5  Input  Circuit  Input  Impedance.  Input  circuit  operating  input  imped¬ 
ance  including  the  effect  of  the  transmitter  shall  be  no  less  than  6,800  ohms 
line-to-line. 

3. 2. 3. 7. 6  Input  Circuit  Off  Impedance.  The  input  circuit  off  impedance  (power 
removed),  including  the  effect  of  the  transmitter,  shall  be  no  less  than  6,800 
ohms  line-to-line,  with  plus  or  minus  6  volts  peak,  line-to-line,  applied  to 
the  input  terminals. 

3. 2. 3. 8  Data  Validation.  Logic  shall  be  provided  in  the  receiving  subsystem 
to  recognize  improperly  coded  signals,  data  dropouts,  or  excessively  noisy  sig¬ 
nals.  Each  word  shall  conform  to  the  following  minimum  validating  criteria: 

a.  The  word  begins  with  a  valid  sync  field. 

b.  The  bits  are  in  a  valid  Manchester  11  code. 

c.  The  word  has  20  bits  plus  parity. 

d.  The  word  parity  is  odd. 

Where  a  word  fails  to  conform  to  the  preceding  criteria,  the  word  shall  be  con¬ 
sidered  invalid  and  shall  not  be  used  by  the  receiving  subsystem.  Where  an  in¬ 
valid  word  sync  occurs,  the  receiving  subsystem  shall  reset  and  wait  for  a  new 
valid  message  sync. 

3.2.4  Type  III  Signals  -  Discrete,  Analog,  and  Digital. 
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3. 2.4.1  Transmission  Lines.  The  discrete,  analog,  and  digital  signals  will 
be  input  and  output  via  two -conductor,  twisted,  shielded,  jacketed  cables 
conforming  to  MIL-C-7078,  or  equivalent.  The  designation  is  (TBD) . 

3. 2. 4. 2  Discrete  Signals.  The  characteristics  of  discrete  signals  shall  be 
in  accordance  with  the  following  subparagraphs. 

3.2.4. 2.1  Electrical  Characteristics.  The  electrical  characteristics  of 
discrete  signals  shall  be  as  follows: 

Signal  Parameter  Characteristics 


a. 

Digital  "one"  state  (true) 

Plus  5  plus  or  minus  1.0  volts 

b. 

Digital  "zero"  state  (false) 

Zero  plus  or  minus  0.5  volts 

c. 

Rise  time* 

1.0  to  20.0  microseconds 

d. 

Fall  time* 

1.0  to  20.0  microseconds 

*N0TE:  The  rise  and  fall  time  shall  be  measured  between  10  percent  and  90 
percent  of  nominal  zero  and  plus  5 -volt  limits  driving  a  resistive 
load  of  IK  plus  or  minus  5  percent  paralleled  with  5,000  picofarads 
plus  or  minus  10  percent. 

3. 2. 4. 2. 2  Discrete  Signal  Output  Circuit. 

3. 2. 4. 2. 2.1  Single  Ended.  Discrete  outputs  shall  last  for  periods  greater 
than  5  milliseconds.  The  output  circuit  shall  be  capable  of  ing  5 

milliamperes  current  minimum  at  plus  4.0  volts,  minimm.  The  outj,  circuit 
shall  be  capable  of  driving  no  less  than  50  feet  of  s ingle -conductor  cable 
having  a  distributed  capacitance  of  100  picofarads  per  foot  with  no  less  than 
four  input  circuits  on  the  line,  each  drawing  1.25  milliamperes,  maximun. 

The  output  circuit  shall  be  capable  of  sinking  10  milliairperes  of  current  in 
the  digital  "zero"  state  at  plus  0.5  volt,  maximum.  Discrete  outputs  shall 
be  single-ended  unless  otherwise  specified  by  the  detail  specification. 
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3. 2. 4. 2. 2. 2  Double  Ended.  Differential  output  circuits  shall  be  provided 
meeting  the  applicable  requirements  of  3. 2. 4. 2. 2.1  (except  that  current  sink¬ 
ing  capability  (false  state)  shall  be  no  less  than  2.5  milliamperes  at  0.5 
volt)  where  the  responsive  time  delay  due  to  line  capacitance  and  input  fil¬ 
tering  is  unacceptable  and  therefore  a  differential  circuit  is  required  by 
the  detail  specification.  The  differential  output  circuits  shall  provide  no 
less  than  100K  ohms  isolation  between  the  input  logic  return  and  the  outputs. 

3. 2. 4. 2. 2. 3  Power-Off  Impedance.  When  de-energized,  the  dc  impedance  of  the 
output  circuit  shall  be  no  less  than  10K  ohms  with  plus  2  volts  applied. 

3. 2. 4. 2. 2. 4  Signal  Ground.  Signal  ground  (return)  shall  be  provided  in  ac¬ 
cordance  with  3. 2.4. 2.4. 

3. 2.4. 2. 3  Discrete  Signal  Input  Circuit. 

3. 2. 4. 2. 3.1  Single  Ended.  Input  circuits  shall  be  compatible  with  the  in¬ 
coming  signal  characteristics.  Differential  receiver  circuits  shall  be  used 
to  detect  discretes  properly  with  a  plus  or  minus  1.5 -volt  signal  ground  dif¬ 
ference.  The  receiver  shall  inteipret  an  input  of  plus  2.0  volts  or  less  dif¬ 
ference  with  respect  to  its  return  line  as  a  digital  "zero"  (false)  and  an  in¬ 
put  greater  than  plus  2.5  volts  as  a  digital  "one"  (true).  Noise  suppression 
or  filtering  shall  be  employed  for  all  lines  driven  by  single-ended  output 
circuits.  Rise  and  fall  times  resulting  from  the  use  of  noise  suppression 
or  filtering  circuits  shall  be  no  greater  than  2  milliseconds.  The  input 
circuits  shall  draw  a  maximum  of  plus  or  minus  1.25  milliampere  in  the  digital 
"one"  state  and  supply  a  maximun  current  of  2.5  milliamperes  to  the  external 
drivers  in  the  digital  "zero"  state.  All  discrete  input  circuits  shall  pro¬ 
vide  overvoltage  protection  of  at  least  plus  or  minus  10  volts  peak.  The 
differential  receiver  shall  provide  no  less  than  100K  ohms  isolation  between 
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its  input  signal  return  and  its  output  logic  return.  The  receiver  shall  in¬ 
terpret  an  open  line  or  the  driver  power-off  impedance  specified  in  3. 2. 4. 2. 3. 3 
as  a  digital  "zero". 

3. 2. 4. 2. 3. 2  Double  Ended.  Differential  input  circuits  required  to  receive 
double-ended  signals  shall  meet  the  applicable  requirements  specified  in 

3. 2. 4. 2. 3.1  except  that  no  noise  suppression  or  filtering  devices  shall  be 
employed  unless  otherwise  specified  by  the  detail  specification.  Input  cir¬ 
cuits  shall  provide  a  maximum  of  80  db  conrnon  mode  rejection  for  levels  of 

at  least  plus  or  minus  10  volts  peak  from  dc  to  1,000  Hz.  The  receiver  shall 
interpret  an  open  line  or  the  driver  power-off  impedance  specified  in 

3. 2. 4. 2. 3. 3  as  a  digital  "zero". 

3. 2. 4. 2. 4  Discrete  Signal  Return  Lines.  Each  discrete  signal  shall  have  a 
return  line,  except  a  maximun  of  10  single -ended  discretes  to  a  single  ex¬ 
ternal  LRU  may  use  a  single  return.  Miltiple  discretes  to  several  LRU's, 
however,  shall  have  a  minimum  of  one  return  line  from  each  LRU. 

3. 2.4.3  DC  Analog  Signals.  The  characteristics  of  dc  analog  signals  shall 
be  in  accordance  with  the  following  subparagraphs. 

3. 2. 4. 3.1  Electrical  Characteristics.  The  electrical  characteristics  of  the 
dc  analog  signal  shall  be  as  follows: 

Signal  Parameter  Characteristics 


a. 

Scaling 

As  specified  in  detail  specification 

b. 

Linearity 

As  specified  in  detail  specification 

c. 

Accuracy 

As  specified  in  detail  specification 

d. 

Output  voltage 

Zero  to  plus  or  minus  5  volts  or  zero 

to  plus  5  volts  as  specified  in  detail 

specification 
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3. 2. 4. 3. 1.1  Transfer.  The  output-input  circuits  shall  be  capable  of  trans¬ 
ferring  a  dc  to  10  Hz  analog  signal  with  an  accuracy  as  specified  in  the  de¬ 
tail  specification  over  the  cable  specified  in  3. 2.4.1. 

3. 2. 4. 3. 1.2  Malfunction.  The  output-input  circuits  shall  not  be  damaged  by, 
or  malfunction  when  subjected  to,  the  following: 

a.  Voltage  of  plus  or  minus  10  volts  peak,  line -to -ground 

b.  Opens 

c.  Shorts  to  ground 

3.2.4. 3. 2  DC  Analog  Signal  Output  Circuit.  The  output  circuit  shall  be 
single-ended  or  differential  as  specified  in  the  detail  specification  and 
shall  exhibit  a  maximum  output  impedance  of  200  ohms.  The  noise  output  of 
the  output  circuit  shall  be  no  greater  than  1  millivolt  RMS.  The  output 
circuit  shall  be  capable  of  supplying  4  milliamperes  minimum  at  plus  5  volts 
nominal.  The  output  circuit  shall  be  capable  of  sinking  4  milliamperes  min¬ 
imum  at  minus  5  volts.  The  output  circuit  shall  be  capable  of  driving  no 
less  than  50  feet  of  two-conductor  cable  with  a  distributed  capacitance  of 
100  picofarads  per  foot  with  no  less  than  four  input  circuits  on  the  line, 
each  drawing  1  milliampere  maximum. 

3. 2. 4. 3. 3  DC  Analog  Signal  Input  Circuit.  The  input  circuit  shall  be  com¬ 
patible  with  the  incoming  signal  characteristics  specified  herein.  The  input 
circuit  shall  be  a  differential  receiver  capable  of  accepting  the  analog  sig¬ 
nal  from  the  output  circuit  specified  in  3. 2. 4. 3. 2.  The  input  settling  time 
shall  be  no  greater  than  1  millisecond  to  within  the  accuracy  required  by 
the  detail  specification.  The  input  circuits  overload  recovery  time  shall  be 
no  greater  than  1  millisecond.  An  open  circuit  shall  cause  the  input  circuit 
to  output  a  voltage  that  represents  the  off-state  of  the  parameter  represented. 
The  input  circuit  conmon  mode  rejection  shall  be  60  db  from  dc  to  1,000  Hz 


C-21 


at  plus  or  minus  10  volts  minimum.  The  differential  receiver  shall  provide 
no  less  than  100K  ohms  isolation  between  its  input  signal  return  and  its  out¬ 
put  logic  return. 

3. 2. 4. 4  Digital  Signal  Interface.  The  characteristics  of  serial  digital 
signals  shall  be  in  accordance  with  the  following  subparagraphs. 

3. 2. 4. 4.1  Data  Code.  The  data  code  shall  be  bipolar  retum-to-zero  (RZ) 
self-clocking  pulse  code  modulation.  A  logic  "one"  shall  be  transmitted  as 
a  positive  pulse  1/2-bit  in  time  length  followed  by  a  dead-time  (zero  volts) 
1/2-bit  time  in  length.  A  logic  "zero"  shall  be  a  negative  pulse  1/2-bit 
time  in  length  followed  by  a  dead-time  1/2-bit  time  in  length  (see  Figure  8). 

3. 2. 4. 4. 2  Word  Formats.  Digital  data  transactions  shall  utilize  two  types 
of  word  formats.  The  two  types  shall  be  designated  as  an  address  word  and 

a  data  word.  An  address  word  shall  be  used  to  specify  data  to  be  transmitted; 
a  data  word  shall  be  used  to  transmit  the  requested  data. 

3. 2. 4. 4. 2.1  Address  Word  Format.  An  address  word  shall  consist  of  9  bits. 
The  first  8  bits  are  available  for  use  as  a  data  address;  the  ninth  bit  shall 
be  a  parity  bit.  The  number  of  bits  used  (up  to  8)  foT  a  specific  data  ad¬ 
dress  shall  be  as  specified  in  the  interfacing  subsystem  detail  specification. 
See  Figure  8  for  address  word  example. 

3. 2. 4. 4. 2. 2  Data  Word  Format.  A  data  word  shall  consist  of  17  bits.  The 
first  16  bits  are  available  for  use  to  transmit  data,  the  17th  bit  shall  be 
a  parity  bit.  The  nunber  of  data  bits  utilized  (up  to  16)  for  a  specific 
data  response  shall  be  specified  in  the  interfacing  subsystem  detail  spec¬ 
ification.  See  Figure  8  for  data  word  example. 
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Figure  8.  Serial  Digital  Output/Input  signals 
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3. 2. 4. 4. 2. 3  Parity.  The  parity  for  both  the  address  word  and  the  data  word 
shall  be  odd  parity.  The  parity  bit  for  both  words,  bit  9  and  bit  17  respec¬ 
tively,  shall  be  set  to  a  logic  "one"  or  "zero"  such  that  the  number  of  logic 
"ones"  for  the  entire  word,  including  the  parity  bit,  shall  be  odd. 

3. 2. 4. 4. 3  Data  Rate.  The  data  bit  rate  for  both  address  and  data  words  shall 
be  1  megabit  per  second  plus  or  minus  10  percent. 

3. 2. 4. 4. 4  Cable.  The  cable  used  to  transfer  serial  digital  signals  shall  be 
two  conductor  twisted,  single  shield,  jacketed  cable  equivalent  to  a  twin  ax¬ 
ial  cable  having  71  ohms  plus  or  minus  10  percent  impedance  and  a  distributed 
capacitance  no  greater  than  50  picofarads  per  foot.  There  shall  be  one  cable 
dedicated  to  the  transmission  of  address  words  and  another  dedicated  to  the 
transmission  of  data  words. 

3. 2. 4.4. 5  Input/Output  Circuit  Characteristics.  The  serial  digital  input  and 
output  circuit  characteristics  shall  conform  to  the  requirements  specified  in 
3. 2. 4. 4. 5.1  and  3. 2. 4. 4. 5. 2. 


3. 2. 4. 4. 5.1  Output  Circuit  Characteristics.  The  output  circuit  shall  conform 
to  the  following  characteristics: 


a. 

b. 


Type 

Output  voltage 


c. 


Common  mode  output 
voltage 


Differential  and  balanced  output. 

Peak  line-to-line. 

Logic  "1"  shall  be  5  plus  or  minus  1.0  volts. 
Dead  time  shall  be  0  plus  or  minus  0.5  volts. 
Logic  "0"  shall  be  minus  5  plus  or  minus  1.0 
volts. 

The  conmon  mode  output  voltage  (measured  from 
each  line  to  the  signal  common)  of  the  output 
circuit  shall  be  no  greater  than  plus  or  minus 
0.5  volt  peak. 
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d.  Output  drive  capability 


The  output  circuit  shall  be  capable  of 
driving  no  less  than  six  serial  digital 
input  circuits,  as  specified  below,  con¬ 
nected  by  no  less  than  50  feet  of  two- 
conductor,  twisted,  single-shielded, 
jacketed  cable  equivalent  to  a  twin  ax¬ 
ial  cable  having  71  plus  or  minus  ten 
percent  ohms  impedance  and  a  distributed 
capitance  no  greater  than  50  picofarads 
per  foot.  The  cable  will  be  terminated 
in  its  characteristics  impedance  (see 
Figure  9) . 

e.  Rise  and  fall  time  150  plus  or  minus  50  nanoseconds  measured 

line -to- line  at  10  percent  and  90  per¬ 
cent  of  the  nominal  zero  to  plus  5 -volt 
and  zero  to  minus  5 -volt  limits  when 
driving  a  resistive  load  of  71  plus  or 
minus  10  percent  parallel  with  2,b00 
picofarads  plus  or  minus  10  percent. 

f.  Short  protection  The  output  circuit  shall  not  be  damaged 

when  subjected  to  shorts  to  ground  or 
a  voltage  of  plus  or  minus  10  volts  dc 
or  ac  peak-to-peak,  line-to-ground. 

3. 2.4.4. 5. 2  Input  Circuit  Characteristics.  The  input  circuit  shall  conform  to 
the  following  characteristics: 

a.  Type  Differential  input. 

b.  Input  voltage  Plus  2.5  to  plus  6.0  volts  peak  line- 

to-line  shall  represent  a  logic  "1". 

0.0  to  plus  or  minus  2.0  volts  shall 
represent  dead  time. 
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Overvoltage  protection 


Input  impedance 


Input  circuit 
compatibility 


Common  mode  rejection 


Frequency 


Minus  2.5  to  minus  6.0  volts  peak  line- 
to-line  shall  represent  a  logic  "0" 

Plus  or  minus  30  volts  common  mode  (dc 
or  ac  peak-to-peak) . 

Plus  or  minus  10  volts  differential 
(dc  or  ac  peak-to-peak). 

4K  minimum  or  71  ohms  plus  or  minus  10 
percent  line-to-line  as  specified  in 
detail  specification. 

Common  mode  to  logic  return:  10K  min¬ 
imum. 

With  power  off,  input  circuit  failure 
or  the  overvoltage  input  (common  mode) 
defined  above  the  impedance  shall  be 
2 OK  minimum. 

The  input  circuit (s)  shall  accept  the 
signals  from  the  serial  digital  output 
circuit  connected  by  the  cable  as  spec¬ 
ified  in  output  drive  capability 
(3.2.4.*  5.1,  item  "d") . 

A  common  mode  voltage  of  plus  or  minus 
10  volts  dc  to  1.0  MHz  shall  not  cause 
a  logic  "1"  or  logic  "0"  to  be  misinter¬ 
preted. 

1  megabit  per  second. 

Noise  filtering  for  pulses  less  than  100 
nanoseconds  wide  shall  be  provided. 


3.2. 5  Type  IV  Signals  -  Analog. 


3. 2. 5.1  DC  Analog  Signal.  The  electrical  characteristics  of  the  dc  analog 
and  associated  input  and  output  circuits  shall  conform  to  the  requriements 
specified  in  3.2. 5. 1.1  through  3. 2. 5. 1.3. 


3. 2. 5. 1.1  Output-Input  Circuit.  The 
the  following  general  requirements: 
a.  Scaling 


b.  Accuracy 

c.  Linearity  error 

d.  Bandwidth 

e.  Malfunction 


output -input  circuit  shall  conform  to 

Plus  or  minus  10  volts,  plus  10  volts 
peak  line-to-line  shall  be  equivalent 
to  maximum  state  the  parameter  may 
normally  attain.  The  minus  value  shall 
be  as  specified  in  the  detail  spec¬ 
ification. 

As  specified  in  the  detail  specification. 
As  specified  in  the  detail  specification. 
As  specified  in  the  detail  specification. 
The  output -input  circuits  shall  not  be 
damaged  by  open  circuit  or  shorts  to 
28  volts,  dc  or  ac  or  ground. 


3. 2. 5. 1.2  Output  Circuit  Characteristics.  The  output  circuit  shall  conform 


to  tie  following  characteristics: 

a.  Type 

b.  Output  voltage 

c.  Common  mode  output  voltage 

d.  Output  impedance 


Differential  and  balanced  output. 

0.0  to  plus  or  minus  10  volts  peak 
line-to-line  (differential). 

0.5  volts  peak  maximum  dc  to  1,000  Hz. 
100  ohms  maximum. 
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e.  Output  drive  capability  The  output  circuit  shall  be  capable 

of  driving  the  input  circuit  specified 
below  connected  by  no  less  than  50  feet 
of  two -conductor,  twisted,  single- 
shield  jacketed  cable  with  a  distri¬ 
bution  capacitance  of  no  greater  than 
50  picofarads  per  foot. 


3.2. 5. 1.3  Input  Circuit  Characteristics.  The  input  circuit  shall  conform  to 


the  following  characteristics: 

a.  Type 

b.  Input  circuit 
compatibility 

c.  Input  voltage 

d.  Input  impedance 

e.  Common  mode  rejection 

f.  Overload  recover  time 

g.  Power  off  and  input  circuit 
failure's  input  impedance 

h.  Balance 

i.  Isolation 


Differential  and  balance  input. 

The  input  circuit  shall  be  compatible 
with  the  output  circuit  signal. 

0.0  to  plus  or  minus  10  volts  peak 
line-to-line  (differential). 

1D0K  ohm  minimum. 

60  db  dc  to  1,000  Hz  for  levels  of 
at  least  20  volts  peak. 

1  millisecond  maximum. 

20K  ohms  minimum  with  input  voltage 
of  0.0  to  plus  or  minus  10  volts. 

The  inputs 's  impedance  shall  be  bal¬ 
anced  to  ground  to  within  2  percent. 
100K  ohms  minimum  between  input  signal 
lines  and  the  receiver  output  circuit 
return. 


3.2.6  Environmental  Conditions.  The  data  transmission  and  receiving  equip¬ 
ment  shall  provide  the  specific  performance  specified  herein  over  the  service 
life  and  environmental  conditions  specified  in  the  detail  specification. 
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4.  QUALITY  ASSURANCE  PROVISIONS 


4.1  Tests.  The  data  transmission  and  receiving  equipment  shall  be  subjected 
to  verifications  to  determine  compliance  with  the  requirements  specified  in 
Section  3  over  the  service  life  and  environments  specified  in  the  detail  spec¬ 
ification.  The  tests  shall  be  an  integral  part  of  the  verification  tests  re¬ 
quired  by  the  detail  specification. 

5.  PREPARATION  FOR  DELIVERY.  No  applicable. 

6.  NOTES.  Not  applicable. 
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APPENDIX  D 


B-l  CITS  TEST  IMPLEMENTATION  SUNMARY 

It  is  desirable  that  all  systems  within  an  aircraft/weapon  system  be 
tested  with  seme  level  of  onboard  test.  The  onboard  test  system  provides 
two  primary  functions: 

1.  To  monitor  the  "general  well  being"  of  the  systems  under  test  and 
inform  the  operator  of  any  malfunctions. 

2.  To  fault  isolate  the  failure  to  the  LRU  level. 

Onboard  test  systems  perform  these  functions  of  fault  detection  and  iso¬ 
lation  by  implementing  test  algorithms  which  utilize  the  techniques  of: 

1.  End-to-end  testing. 

A.  Command  to  response. 

2.  Limit  testing. 

A.  Test  parameter  to  fixed  limit. 

1.  Pressure  -  high  or  low. 

2.  Temperature  -  high  or  low. 

3.  Flow  rate  -  high  or  low. 

4.  Speed  -  over  or  under. 

5.  Voltage  -  over  or  under. 

6.  Frequency  -  over  or  under. 

7.  Current  -  over. 

B.  Test  parameter  to  calculated  limit. 

1.  Pressure  -  high  or  low. 

2.  Speed  -  over  or  under. 

3.  Temperature  -  high  or  low. 

3.  Comparison  testing. 

A.  Input  to  output. 

B.  Parameter  to  parameter. 

C.  Parameter  to  average. 
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D.  Channel  to  channel. 

E.  Bit  status  to  pattern  recognition. 

An  onboard  test  system  utilizes  these  test  techniques,  in  various  combi¬ 
nations,  to  logicaly  determine  the  status  of  each  aircraft  system  tested. 

When  an  out  of  tolerance  condition  is  detected,  the  test  system  expands  these 
techniques  to  isolate  the  failure  to  the  failed  line  replaceable  unit(s). 

The  B-l  CITS  onboard  test  system  implementation  was  based  on  these  basic 
testing  techniques.  Tests  mechanized  in  the  B-l  CITS  onboard  test  system  are 
provided  as  examples  of  the  types  of  tests  implemented,  the  effectiveness  of 
the  tests,  the  problems  experienced  and  additional  tests  reconmended.  These 
tests  are  shown  as:  good  (G) ,  satifactory  (S) ,  poor  (P) ,  and  reconmended  (R) 
and  are  provided  in  Tables  I  through  X. 
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TABLE  I 


B-l  CITS  Tests  for  Electrical  Power,  Electrical  Multiplex,  and  Proximity  Switch 

Subsystems 


NOTES:  1. 

2. 


3. 


4. 


5. 


6. 


Basic  test  is  good  but  input  buffer  failures  cannot  be  readily  detected  or 
isolated. 

Although  Cl  memory  failures  seldom  occur,  these  failures  cannot  be  readily 
detected  or  isolated. 

Only  3  of  5  protective  functions  which  result  in  generator  trips  are 
available.  Also,  present  test  mechanization  does  not  provide  for  any 
charge  pressure,  PMG,  or  circuit  breaker  checks  until  a  generator  line 
contactor  is  initially  closed. 

Battery/charger  failures  require  a  one  hour  time  delay  before  failure 
is  flagged. 

Erroneous  bus  tie  failures  are  indicated  due  to  the  addition  of  cockpit 
over-ride  switches. 

Individual  protective  function  time  delays  and  status  are  not  checked. 
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Steering  and  Damping,  Landing  Gear,  and  Braking  and  Anti-Skid  Subsystems 


Hardware  deficiency  -  noise  susceptibility. 


TABLE  III 

B-l  CITS  Tests  for  Propulsion  System 


NOTES: 


1.  Specific  operating  limits  were  difficult  to  determine  until  actual 
night  test  data  was  obtained. 

2.  Determination  of  proper  test  preconditions  is  critical. 

3.  Controller  software  problem  unresolved  -  test  discontinued. 

4.  Timing  of  events  was  determined  from  flight  test  data. 

5.  A  time  delay  was  added  to  mask  an  un correctable  characteristic 
of  all  data  from  one  side  of  the  EIS  SCDU,  going  to  zero  for  one 
second,  then  back  to  normal. 

6.  Did  not  function  properly  because  the  changing  rate  of  the  two 
checksum  values  was  not  conpatible  with  the  available  sanpling 
rates  of  the  CITS. 
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Discrete  Active  Test 


TABLE  IV 


B-l  CITS  Tests  for  Bleed  Air,  ECS,  Fire  Protection,  and  Crew  Escape 

Systems 


\.  TESTS 

(C  =  Comparison  Test,  E  =  End-to 

End  Test) 

SUBSYSTEMS  N. 

LIMIT  TESTS 

(C) 

(E) 

Trip  Level 

Pressure 
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Position 

Drive  Command 

Speed 

Delta  Pressure 

Altitude 

Controller  Validity 

Self-Test 

Bleed  Air  Leak  Detection 

G 

G 

Bleed  Air  Distribution  and  Pressurization 

G1 

G3 

IT 

G5 

G6 

ECS  Air  Conditioning  and  Pressurization 

G2 

G 

“G4" 

G 

S7 

G 

G 

Fire  Detection 

G 

G8 

Fire  Extinguishing 

G 

Crew  Escape  and  Safety 

G 

G 

G 

NOTES: 


1.  Discrete  pressure  switches  become  contaminated  resulting  in  shift  in 
pressure  trip  points,  producing  false  indications. 

2.  Discrete  pressure  switch  setpoints  were  improperly  selected. 

3.  Discrete  temperature  switch  setpoints  were  improperly  selected  and 
response  rate  was  slower  than  analog  sensors. 

4.  Proximity  switch  adjustment/alignment,  rigging,  and  scoop  flexing 
caused  proximity  switches  to  move  out  of  target  range,  resulting 
in  improper  position  indications. 

5.  Discrete  drive  command  was  difficult  to  set  in  order  to  determine 
drive/no-drive  status  of  bleed  air  temperature  control  valve. 

6.  Discrete  RPM  sensor  setpoint  for  bleed  air  precooler  blower  is 
difficult  to  set  and  change. 

7.  Delta  pressure  sensor  for  ECS  filter  analog  signal  range  from 
+5V  to  -5V  with  zero  volts  being  a  go  condition.  Failure  at 
zero  volts  cannot  be  detected. 

8.  Signal  stability  problems  due  to  inproper  or  poor  termination  of 
ground  return  wire  at  connectors.  Problem  corrected  with  improve! 
manufacturing  procedures. 
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TABLE  V 


B-l  CITS  Tests  for  Fuel  System 


NOTES:  1.  Stimulus  input  circuitry'  in  Interface  Device  (ID)  was  very  sensitive. 

Minor  noise  on  the  aircraft  wiring  would  trigger  ID  self -test.  Mod¬ 
ification  to  ID  input  circuitry  identified  to  correct  problem. 

2.  Punp  pressure  switches  indicate  pressure  when  pump  was  "OFF’  and  no 
pressure  when  punp  was  "ON"  with  a  high  fuel  rate.  Recommend  RPM 
sensor  be  implemented  to  determine  punp  running. 

3.  Fuel  flow  test  required  many  preconditions  to  determine  flow/no-flow 
condition.  This  in  conjunction  with  pressure  switch  problem  above 
combine  to  make  this  test  ineffective. 


END-TO-END  COMPARISON  LIMIT 


B-l  CITS  Tests  for  Pitch,  Roll,  and  Yaw  Stability  Control  and  Augmentation  Subsystem  (SCAS) 
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The  accuracy  of  the  analog  multiplex  circuitry  in  the  SCAS 
controllers  was  inadequate. 

Analog  multiplexing  on  signals  being  compared  was  marginal 
due  to  time  required  to  access. 


B-l  CITS  Tests  for  Flap/Slat,  Structural  Mode  Control,  and  Wingsweep  Subsystems 
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TABLE  IX 


B-l  CITS  Test  for  the  Hydraulic  Subsystem 


NOTE: 

1.  The  pressure  tests  for  hydraulic  power 
caused  problems  because  vibration  on 
the  aircraft  caused  the  pressure  signals 
to  exhibit  excessive  noise.  Notch  fil¬ 
ters  were  added  to  reduce  the  noise  from 
the  sensor. 
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B-l  CITS  Tests  for  Weapon  Bay  Door  Drive  and  Rotary  Launcher  Drive  Subsystems 
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\ L  =  Limit  tests) 

SUBSYSTEMS  \ 

Weapon  Bay  Door  Drive 
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Hardware  deficiency;  encoder  status  is  momentary,  not 
continuous. 


